Posts

Showing posts with the label forensics

Forensically Sound Evidence

Mike Murr pointed me to his blog post Forensically Sound Duplicate . He suggests replacing this definition of a forensically sound duplicate with the one that follows. "A 'forensically-sound' duplicate of a drive is, first and foremost, one created by a method which does not, in any way, alter any data on the drive being duplicated. Second, a forensically-sound duplicate must contain a copy of every bit, byte and sector of the source drive, including unallocated 'empty' space and slack space, precisely as such data appears on the source drive relative to the other data on the drive. Finally, a forensically-sound duplicate will not contain any data (except known filler characters) other than which was copied from the source drive." This is Mike's replacement: "A forensically sound duplicate is a complete and accurate representation of the source evidence. A forensically sound duplicate is obtained in a manner that may inherently (due to the acquistio...

Forensics Warnings from CIO Magazine

The April 2006 issue of CIO Magazine features an article called CSI for the Enterprise? . It addresses the rise of electronic data discovery (eDiscovery in some quarters) tools. For a management magazine, the article makes several useful points: Beware the Forensics Label Many salespeople attach the label "forensics" to their security and compliance analysis tools, and that can be very misleading. In law enforcement circles, "forensics" means a well-defined set of discovery and investigative processes that hold up in court for civil or criminal proceedings. An enterprise that relies on these tools' records or analysis in, for example, a wrongful termination suit, is probably in for an unpleasant surprise. "It may not hold up in court," says Schwalm, a former Secret Service agent. "Very few vendors have an idea of what the requirements [are for proof, from a legal perspective]. They're really providing just a paper trail. You should challen...

Pulling the Plug in 2005

Every time I attend a USENIX conference, I gather free copies of the ;login: magazine published by the association. The August 2005 issue features some great stories, with some of them available right now to non-USENIX members. (USENIX makes all magazine articles open to the public one year after publication. For example, anyone can now read the entire December 2004 issue.) An article which caught my eye was Forensics for System Administrators by Sean Peisert . Although the USENIX copy of the article won't be published until August 2006, you can read Sean's copy here (.pdf). I thought the article was proceeding well until I came across this advice. "What happens when there is some past event that a system administrator wishes to understand on their system? Where should the administrator, now a novice forensic analyst, begin? There are many variables and questions that must be answered to make proper decisions about this. Under almost all circumstances in which t...

Guidance Software 0wn3d

This morning I read stories by Brian Krebs and Joris Evers explaining how Guidance Software , maker of host-based forensics suite Encase , was compromised. Guidance CEO John Colbert claims "a person compromised one of our servers," including "names, addresses and credit card details" of 3,800 Guidance customers. Guidance claims to have learned about the intrusion on 7 December. Victim Kessler International reports the following: "Our credit card fraud goes back to Nov. 25. If Guidance knew about it on Dec. 7, they should have immediately sent out e-mails. Why send out letters through U.S. mail while we could have blocked our credit cards?" Guidance could face severe financial trouble. According to reporter Joris Evers: "Guidance stored customer names and addresses and retained card value verification, or CVV, numbers, Colbert said. The CVV number is a three-digit code found on the back of most credit cards that is used to prevent fraud in onlin...

Network Forensics? Please.

Today I looked at the Interop New York 2005 Schedule and noticed an item called "Network Forensic Day" taught by Pine Mountain Group . I try to stay current with people and companies performing security work, but I had never heard of PMG. I looked at the description of the course, wondering if the "network" meant "enterprise," as in "how to use forensics in the enterprise." I think that is a misapplication of the term network in that context, but it's common enough. Alternatively, perhaps "network" meant "traffic," which is how I use the term. When I mention "network forensics," I define it as the art of collecting, protecting, analyzing, and presenting network traffic to support remediation or prosecution. This is in line with the definition of forensics : "1. The art or study of formal debate; argumentation. 2. The use of science and technology to investigate and establish facts in criminal or ci...

Using md5deep

Thank you to Harlan Carvey for reminding me of Jesse Kornblum's md5deep . md5deep is a suite of tools to recursively compute a variety of hashes. It is not limited to the MD5 algorithm. In the example below I run the sha256deep tool to provide sha256 hashes of various files. The -r flag initializes recursive behavior, and -z says display file size before the hash. bourque:/home/analyst$ sha256deep -r -e -z * 93506 1a6da6a2a849eb27fb7522939afab63ec59bcdb9412c2460fe611543b573d95f /home/analyst/2005-041-santini_air/sample 111 43450978e07f87dfbc4918fec928209c54f4d5804367960fbde617e71ee50985 /home/analyst/2005-041-santini_air/sample.sha256 209.180.018.089.02001-156.023...: 391MB of 1405MB done, 00:01:22 left The last entry shows sha256deep is busy computing the hash for a 1405 MB file. By passing the -e flag, I told the program to estimate time until hash completion. This is useful for processing large files. The resulting hash is eventually shown below. 147357...