Join Us!

evidence collection...
 
Notifications
Clear all

evidence collection methodolgy for forensic investigation  

Page 2 / 3
  RSS
arashiryu
(@arashiryu)
Active Member

Boot your acquisition system with HELIX Forensic CD ROM. You can use GRAB to acquire a live system over the network. It took me some time and effort to get comfortable with it but once you have mastered the commands, it is second nature.
I own Prodiscover as well. Depending upon the client's budget and depending on the situation and the investigation, I use Prodiscover and GRAB from HELIX accordingly.
I am currently playing with Symantec Livestate which lets you image over the network as well. I am struggling with the fact that it deploys an agent thus modifying evidence, which I am not comfortable with. But it might work well in private/enterprise/corporate enviornments where you have the agent as a part of the basic image for the workstations and is predeployed. So technically there would be no modification.

Why am I playing with Symantec LiveState? Recently I was hired for a case where the private company suspected that there was some Instant Messenger usage directly from a Windows 2003 Server. The group policy (GPO) enforced on the XP workstation did not allow for instant messenger to run. So how could this be? Because the group policy (GPO) applied on the server was different and did not retrict Instant Messenger. So some smarty pants on 2nd or 3rd shift who must be entirely bored figured he would find a way around it. What he was doing is that he would remote into the server via Dameware Mini Remote Control from his workstation. Started his session and chat away.

I told the client that I need to get a image of the server so I would need 2 - 3 hours downtime. Well, that was not welcomed at all. The server facilitated some reports that remote users ran over VPN, it was also the accounting server with Solomon loaded on it. I noticed (when i was checking in add/remove programs for AIM, Yahoo etc.) that Ghost 9.0 was loaded on the server for some reason. They did not want to spend money on Prodiscover. I chose to use the existing Ghost software to get a live image of the server to my externally connected usb drive.

I was able to acquire the ghost image (sector by sector copy by disabling smart sector copying). When I tried to import it for analysis in Access Data FTK, it was not recognized. But I have discoverd a trick.
I loaded Ghost 9.0 on my forensic workstation. Ghost 9.0 lets me mount the image I acquired as a logical drive. Then I used FTK imager to get a raw image of the mounted ghost image. Hope this works.
It did. I was able to get a raw image from mounted ghost image. I decompressed the raw image to a external usb and made it bootable.
Now I had the server from the image as I would have if I took it down and imaged it locally.

Fruitful end result. I was able to gather evidence without taking the server down. I also successfully finished the analysis and determined the guilty party and case was closed.

Lesson learned.
It is possible to acquire evidence in a forensically sound manner as long as you follow a methodical process even if you are challenged with a enviornment that would challege gathering sound evidence. You cannot expect to walk into any enviornment and expect to gather evidence like every other case. It will vary case by case basis.

PS I have duplicated this successfully in my lab and am able to reproduce same results. Sorry for the lengthy post. I am not in CHAT MODE like our guilty party was. ;~)

ReplyQuote
Posted : 16/11/2005 8:04 pm
phius
(@phius)
Junior Member

Harlan

Paul…I'd greatly appreciate knowing a bit more about who "we" are (in your post you mention "we" several times). Particularly b/c I am very hesitant to use the words "live" and "forensics" together myself, mostly due to the purist stance that live isn't forensics.

Can you specify the live data that you collect from systems, and perhaps even the methodology and order of that data?

"we" simply refers to the organisation that I work for. As for "Live Forensics" as a terminology, I have no desire to get into semantics with you (I have enough arguments with the "purists"in my office). Whilst I will continue to call it that here in my office, if you provide me with alternate terminology I will be delighted to use it to keep you happy roll

OK…. that out of the way, as for the order that we conduct our live this is how we are approaching (Windows) malware investigations at present

1. Consult Sysadmin if we can use the switch Span port - if so, we plug in an analysis notebook with Ethereal with filters to to sniff the traffic for the target machine. If a busy machine, we will filter out normal traffic. Length of time for sniffing will depend on the circumstances ~ 1/2 - 2 hours is about as much as we can normally afford.

2. If Span port is not available, we plug a hub into the switch and very briefly disconnect the target system before reconnecting it to the switch via the hub. We can then connect the analysis notebook into the hub and sniff traffic as per the above. This is not particularly advisable unless unavoidable as even a couple of seconds break in network traffic could cause data corruption.

We have had good success in following the TCP streams to identify the upstream BotNet controller. As Hogfly rightly points out, this can also be identified by reverse engineering the malware, but by doing the live part you can confirm that it is active and you can also pinpoint the malware - something that may not be so easy on a dead machine.

3. The next step we (currently) use is then to run Helix on the target system and send all the live data (using WFT) to the acquisition machine using Windows shares on a separate hard drive attached to the acquisition machine via firewire.

4. Similar to the above, we then acquire the RAM using Helix

5. At this point there are alot of variables, depending on time available and the case circumstances. Most servers are configured with a small system drive and a large data drive. If that is the case, then we would normally just acquire the system drive as that is where the malware will reside. If we have time to quickly analyse the live data, then we can try to pinpoint the malware and simply extract this.

Now, although I am referring to Helix in the above, as I mentioned in my previous post we are looking at ProDiscoverIR and I have been very impressed with using it in situations involving Windows systems… however, we are still unable to get it to function with Linux systems.

I believe that the ProDiscover model is the way forward for us. Simply inserting the PDServer disk to autorun in the target system is a great method that is easily used by any of our investigators and can be very simply explained. All the analysis is then done on the investigators computer. I particularly like the compare hash function, which allows quick identification of "known" malware or rootkits on a target system.

Ideally, a combination af the nice presentation and detailed analysis of Helix's WFT with ProDiscover's methodology would really suit us.

To Harlan, I have bought your book & it is a good piece of work. However, for reasons stated above, we have not considered using your scripts in actual investigations.

Uh…thanks. But what were the reasons again? I'm curious, as the FSP operates in a manner similar to ProDiscover, collecting data using the FRU and sending it out over a socket to the FSP. I'd be interested to hear your thoughts on why you have not considered using the scripts.

Harlan… The reasons I implied were simplicity. Compare the ready made PDServer disk which our investigators have to do nothing except insert a CDROM and then click commands on the ProDiscover interface to retrieve data - an interface that is quite intuitive and fast and efficient. At the end of the day, that is what we need. I am encouraged to hear that you wll be working with ProDiscover, because the extensive nature and output presentation of your scripts is something that could definitely enhance this tool.

Hogfly… you once again make some good points in your post & wouldn't it just be perfect if every system aministrator was ready for such investigations D. For the time being though, we will stick to conducting live wherever possible, as this provides us with enough data to investigate most cases, and we use standard operating procedures which can suit most cases - at least until our investigators develop more experience anyway.

As to programming our own tools - we have unsuccessfully been down that road before & have learned some important lessons. Probably the most important being that in legal proceedings it is better to use a tool that many others are using if you want acceptance and an easy life!! real life dictates that wherever possible you avoid discussion/arguments over tool or technique specifics… very sheep-like I know, but once again it is reality!!

Arashiryu… that was a good post. I will try & reproduce some of your methods when I have time!!

Thanks for all the feedback… we have a long way to go before live becomes mature & these discussions are very healthy!! We are certainly open to making changes to please let me know if you think we are going about this the wrong way!!

Thanks

Paul

ReplyQuote
Posted : 17/11/2005 8:17 am
mdshukri
(@mdshukri)
New Member

what you can do is, combining the dd and nc command (from your own cd of course) , and send the drive image over through network to your examination pc. However, your binaries must be able to run in the Unix system of your choice. E.g, Sun or HP-UX

ReplyQuote
Posted : 17/11/2005 9:23 am
hogfly
(@hogfly)
Active Member

I would like to propose a term to be used instead of live forensics. Typically, forensics is used as a blanket term for forensic science(purist forensics) and incident response. However, this doesn't encompass what we are discussing which is infact a combination of the two. So, why not call it forensic incident response(TM)?

One of the most lacking areas regarding forensic incident response is a tool that provides correlation of discovered data from a live system. Anyone have ideas on that subject?

Phius,
As a side note in identifying botnets, an nmap scan that probes the ports of the affected systems helps immensely. Not only will you get a banner response from most, you will get a port signature that can be used to detect other similarly affected systems. In addition, network signatures(like JOIN|NICK etc commands) captured via tools like ngrep help as well.

ReplyQuote
Posted : 17/11/2005 9:46 am
phius
(@phius)
Junior Member

Hogfly… I like the Forensic IR name. However, I think the issue that most "purists" have is with the use of the word "Forensic" (although a quick look at dictionary.com shows the definition to be The use of science and technology to investigate and establish facts in criminal or civil courts of law)

I like your idea of running NMap - this information can be correlated with the open port info from the WFT report. As for NGREP, I have to confess that this is the first that I have come across this tool & have just downloaded it to test… thanks for the info

Paul

ReplyQuote
Posted : 17/11/2005 11:26 am
keydet89
(@keydet89)
Community Legend

Hogfly,

One of the most lacking areas regarding forensic incident response is a tool that provides correlation of discovered data from a live system. Anyone have ideas on that subject?

Check out my book. I include a Perl script that correlates collected information, displaying everything in PID-delimited format. This sort of thing is something I haven't seen done anywhere else.

Harlan

ReplyQuote
Posted : 17/11/2005 8:13 pm
hogfly
(@hogfly)
Active Member

harlan,
Oh I agree with you completely. Your script is great and works extremely well with FSP.

ReplyQuote
Posted : 17/11/2005 10:26 pm
ellac
(@ellac)
New Member

Thank you everyone for your valuable input. I like the term forensic IR, but does this term includes forensic analysis as well? The reason I asked is that my paper is all about evidence collection. I don't want to get into analysis on my paper. So I want to make sure if it is suitable for me to use this term.

I agree with many of you saying that dd, nc are the primary tools that I need for collecting evidence. There are tons of paper about such kind of evidence collection but many of them require to take the system offline. I would like to perform such operations when the system is up and running (I need to bring some new ideas on this paper so that's why I want to emphasis the investigation is done on a live system). Any new ideas that can make my paper more interesting will be great.

On a side note, if a firm has a RAID 5 system with four 50GB HD, will you recommend to use dd to get an image? It is cheap to get a 200GB HD these days. However, it will take a long time to transfer data over.

As I have mentioned before, I am a newbie here… pardon me if I ask stupid questions here.

Thank you very much.

Ella

ReplyQuote
Posted : 20/11/2005 5:33 am
arashiryu
(@arashiryu)
Active Member

You can run WinHex Forensic edition from a CD ROM on a live system without taking it down. WinHex also has a built in feature called "Assemble Raid System".

ReplyQuote
Posted : 21/11/2005 8:07 am
phius
(@phius)
Junior Member

Ella,

To come back to your original message, if you can come up with a methodology for conducting Forensic IR on a Linux machine then it would be well received. You can see from this forum that most automated tools are designed for Windows - a similar process for Linux (ie execute a server on the target system to open communication channels in the least intrusive way possible, and then execute commands to capture live data using a tool on the investigation machine). Once again at the risk of being flamed for needing automated tools, most investigators don't have the time or depth of knowledge to do otherwise.

Good luck

Paul

ReplyQuote
Posted : 21/11/2005 2:58 pm
keydet89
(@keydet89)
Community Legend

I'd suggest taking a look at the Forensic Server Project (FSP)

http//www.windows-ir.com/fsp.html

While the project was written *on* Windows, it is not specific *to* Windows. The server portion can be run on Linux, and platform-specific clients (ie, First Responder Utility, or FRU) can be written for any platform, using any language.

Harlan

ReplyQuote
Posted : 21/11/2005 4:16 pm
phius
(@phius)
Junior Member

Harlan,

I don't mean to be negative about your work, as you are doing some great things & it has helped me learn alot about this subject. However, I think the use of perl was summed up quite accurately by one contributor in another thread - Click here to view

For real world investigations, what I am looking for is essentially ProDiscover - pop in the server CD & connect to it with the investigation box using a nice intuitive GUI - no complex pre-installations. This works beautifully for us in Windows, but still struggling in Linux. Right now we are up to our eyeballs in Windows cases so it is not on my urgent list, but I will no doubt be speaking to Technology Pathways soon to try & resolve it.

Please don't take this the wrong way - I am open to be convinced if you provide me with a simple and fast methodology on a par with ProDiscover?

Thanks

Paul

ReplyQuote
Posted : 23/11/2005 7:05 am
keydet89
(@keydet89)
Community Legend

Paul,

At this point, I don't think I'll be able to convince you.

ProDiscover is a great tool, without question.

The FSP is simply another tool. The purpose of it is to allow for the rapid collection of volatile data from a system, minimizing the interaction required by the first responder. Drop the CD containing the FRU (compiled into a standalone EXE…which is provided in the download from my site) into the CD tray of the victim system, fire up the FRU, select the server IP and port, and the .ini file to parse, and that's it. Everything else is handled by the tools, to include detailed logging/timestamping of activity.

The FRU can run any third party CLI tool and send the output off to the server for timestamping and archiving. This includes dumping the contents of the clipboard and protected storage, etc., etc.

Based on your comments, and especially those regarding Perl, it's clear that the issue is more one of zero-knowledge response. My concern is that there are presentations going on a conferences such as Blackhat and DefCon that specify anti-forensics techniques to be used against the analyst, rather than the forensic analysis tools themselves.

Finally, you state that you're looking for something with "no complex pre-installations". The FSP and the FRU ship with their source (ie, Perl scripts) and compiled/tested standalone EXEs. The "installation" is no more complex than what is required with ProDiscover.

Harlan

ReplyQuote
Posted : 23/11/2005 4:30 pm
phius
(@phius)
Junior Member

Harlan,

Based on your comments, and especially those regarding Perl, it's clear that the issue is more one of zero-knowledge response. My concern is that there are presentations going on a conferences such as Blackhat and DefCon that specify anti-forensics techniques to be used against the analyst, rather than the forensic analysis tools themselves

Yeah… I know what you are saying and it goes against my own personal opinions to have to defend the need for simplicity. But…we have a large caseload and I'm afraid that levels of knowledge vary widely among the investigators. The Live IR (see… not using the word *forensics* nowD) that we are doing at the moment is primarily aimed at analysing malware. essentially the investigators are simply collecting the information for later analysis back in the office by specialists. By and large, all we need is a netstat, fport, brief traffic capture (ethereal) and a copy of the system drive. Mostly we are using Helix (as it is free) & we will use ProDiscoverIR for the cases that are more important.

Anyway, please don't get the idea that I am set in my ways against using FSP. I can tell you that we won't be using it on Windows systems as we have established procedures using Helix & ProDiscover. However, I will be testing it's functionality when examining Linux systems as soon as I have some time…

Cheers

Paul

ReplyQuote
Posted : 24/11/2005 7:57 am
keydet89
(@keydet89)
Community Legend

> essentially the investigators are simply collecting the information for
> later analysis back in the office by specialists.

This is rather easy to do with the FSP, and is also highly customizable. Create your own .ini file for use with the FRU, and you've got an easy to use tool. You do updates when you need to, not when some commercial developer feels that it's necessary.

> By and large, all we need is a netstat, fport…

This is what the FRU/FSP framework was designed for.

It's easy…put the fruc.exe file and associated DLL on a CD, along with tools (ie, fport.exe, openports.exe, netstat.exe, tlist.exe, etc.) and an .ini file that contains the necessary commands to run the tools. To make things even easier, include a batch file that launches the fruc.exe file…the only interaction required by the first responder is to type in the name of the batch file, followed by the IP address of the server (and the port, if you're not using a standardized one that can be added to a batch file).

The FRU/FSP automates all of this and minimizes interaction required by the user.

Harlan

ReplyQuote
Posted : 28/11/2005 6:02 pm
Page 2 / 3
Share: