Matt, Use of the swab option will probably destroy the integrity of your forensic image. You do want to use the conv=noerror option, on the other hand. Handling read errors in a robust manner is one of the requirements of a trusted forensic application. Mandia and Prosise have a section in their book (Incident Response. Investigating Computer Crime. New York 2001) on using dd and netcat to gather forensic evidence. It is well worth the read. The standard *nix releases of DD and netcat have a number of known limitations for forensic applications. Releases of DD and other tools specifically designed for forensic purposes may be found at http://prdownloads.sourceforge.net/biatchux/dcfldd-1.0.tar.gz; and http://users.erols.com/gmgarner/forensics. A review of DD and other standard imaging tools may be found at http://www.scmagazine.com/scmagazine/2000_09/survey/survey.html. >> Run "dd.exe if=\\.\C: bs=512 | nc.exe a.b.c.d 4000" on my Win 2000 box.<< The implications of this command line require further discussion and I do not believe that other posters have picked up on this. One of two things may be inferred from this command line: 1. Either you are using a Windows 2000 box as your forensic workstation to image a drive that previously was seized from a suspect computer; or 2. you are running DD on the "live" Windows system. In either case my question is, "Why are you doing this?" At some point a judge (and probably your AG) will expect you to answer this question as well. 1. Under the first scenario, the suspect system either was powered down when you arrived on the scene or you elected to power the system down during your incident response. Your goal is to acquire a forensic image onto a Linux computer. So why are you using Windows 2000 for your imaging solution? Why not just boot to Linux and use the standard *nix version of DD? Microsoft Windows 2000 or XP are not suitable as a forensic imaging platform (under this scenario) unless some form of write-blocking hardware or software is employed to prevent alteration of the original evidence during the imaging process. Since you are apparently trying to image an IDE drive, you may want to check out the ATA/firewire bridge products at http://www.granitedigital.com. While their web site does not advertise a read-only bridge option, I am informed by Mr. Ken Toussaint (infoat_private) that they will burn a read only E-Prom for an additional $20.00. 2. The second scenario is the more interesting one. I do not believe that we have previously discussed in this forum the standards for acquiring a forensic image from a live system and the reasons for doing so. Perhaps it is time that we did. Computer forensics (like information technology in general) is a rapidly evolving discipline. One uses the term "standard practice" in reference to computer forensics at one's own risk. The application of "forensics" to incident response is a new and emerging practice. Until relatively recently, most authors approached computer forensics from the perspective of law enforcement. The perspective of the incident handler is very different from the perspective of law enforcement or the traditional forensic *lab*. Law enforcement is primarily concerned with serving the interests of justice. Neither law enforcement nor traditional forensic labs are likely to encounter a "live" suspect system or an incident that is in-progress. Law enforcement generally is not called to the scene until there is reason to believe that a crime has been committed. By contrast, an incident handler is usually the first (or perhaps second, if he is not the sys-admin) to arrive on the scene of a probable incident. An incident handler is called to the scene because something suspicious is going on. The suspicious activity may or may not be the result of criminal behavior. You don't know at the outset. But the system is usually "live". While there sometimes are statutory reporting requirements, the incident handler is primarily concerned with preserving and protecting the systems within his or her charge, not with law enforcement. The gathering and preservation of evidence will serve this primary overarching goal. Authors are only beginning to grapple with the when, why and how of acquiring a forensic image from a "live" system and the appropriate standard of evidentiary integrity is not always clear. An image acquired from a "live" system may be considered "volatile" data and the practice is perhaps best discussed within this framework. Mandia and Prosise recommend not gathering evidence from a "live" system unless there is evidence of an ongoing network-based crime. This probably would be a good rule of thumb except that the incident handler may not be aware that a *crime* has been committed until after the evidence has been collected and analyzed. A better rule would be to not gather evidence from a "live" system unless there is evidence of ongoing network-based activity that violates company or agency policies or otherwise threatens continued system operation and integrity. Stated another way, the proposed rule is, "Do not gather evidence from a "live" system unless the evidence is pertinent to your investigation and you are unable (for economic, policy or technical reasons) to acquire the same evidence by more conventional means (e.g. by pulling the plug and imaging the drive in a laboratory setting)." It is impossible to gather evidence from a "live" system without modifying the system (and hence the evidence) in some respect (i.e. by leaving artifacts). However, the investigator should gather evidence in a manner that *minimizes* changes to the subject system and the investigator should be able to document and explain the artifacts of the method employed to gather the evidence. To the extent possible, the tools employed to gather evidence should be run from an incident response cd or floppy and *not* from the subject hard drive. A drive should be imaged from a live system only after more volatile evidence (e.g. the contents of physical memory) has been collected from the system. Do not attempt gather evidence from a live system if you believe that the system has been booby-trapped. The validity of evidence gathered from a "live" system depends upon the extent to which the system has been compromised. A kernel-mode key stroke monitor probably will not invalidate evidence gathered from a "live" system. However, if there is reason to believe that core system binaries have been compromised, it will be necessary to terminate the subject system and image the drive in the conventional manner in order to validate evidence previously gathered from the live system. Always use a tool that computes a cryptographic checksum "on the fly" to guarantee evidence integrity when imaging a "live" system. This is necessary because the evidence on a live system is constantly changing as the result of normal system activity. Evidence gathered from a "live" system represents a single "snapshot" in time. Note that the standard *nix releases of DD and Netcat do not do this. Evidence should only be collected from a "live" system (or any other system) in accordance with an established company or agency policy that includes pre-approved responses to common incident scenarios. An incident response policy should be feasible in the light of available human and other resources. Information should be gathered from a live system only by experienced incident handlers. If experienced incident handlers are not available, then terminating power and imaging by conventional methods is probably the best option. I would be interested in knowing what criteria others are using for deciding to acquire an image from a "live" system (*nix or Windows) and what you think the appropriate standards should be for acquiring the evidence in a forensically sound manner within the incident response context. Regards, George. -----Original Message----- From: Estes, Matt CPR / FCBS [mailto:Matt.Estesat_private] Sent: Friday, May 31, 2002 12:33 PM To: forensicsat_private Subject: DD -> Netcat NT Imaging Just wanted to know the forensics comments for doing the following. The practical applications are amazing (and free), but maybe I'm just catching up with the norm. Run "nc -l -p 4000 | dd of=/dev/hdb1 bs=512 conv=swab" to setup a netcat server piping to hdb1 partition on my linux box. Run "dd.exe if=\\.\C: bs=512 | nc.exe a.b.c.d 4000" on my Win 2000 box. swab option was necessary because somewhere along the way the bytes were swapped (network ordering? compiler differences with nc.exe?). Instant bit copy of the partition across the network... and no annoying overhead. I believe this would work as live imaging of harddrives for analysis (comments appreciated). But, it's also a network drive imaging system that fits on a floppy and works between OS's. Matt ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Tue Jun 04 2002 - 04:34:15 PDT