A New Live Triage Tool Taking Shape, Part 1
The Carnivore Digital Forensic System... doesn't actually exist... yet. Rather, the vision I have in my head that represents what the platform is supposed to be hasn't yet become reality. What has become reality is the first step toward that goal... CarnivoreLE.
What is now CarnivoreLE started a few years ago as a way to address live and volatile data on a suspect machine without losing it when the power was eventually pulled away. To better explain why this was of interest to me, I'll take you back to 2001.
In 2001, I was assigned as a task force officer to one of the FBI's field division offices participating in their Innocent Images National Initiative - an investigative task force focused on Internet crimes against children and technology-facilitated child exploitation. We were trained in the common practice of pulling the plug on suspect computers that were found running during a search and transporting those computers to an FBI digital forensic lab for analysis. To even think of touching a keyboard or mouse while the system was live was punishable by death and dismemberment. Well, maybe not that, but it was still a strict no-no.
Later, after kicking off the Arkansas branch of the national Internet Crimes Against Children Task Force (ARICAC), the topic of forensically-sound previews had begun to circulate around digital investigation circles across the country, particularly at the national ICAC level. A version of Knoppix that had been customized and remastered by some of the smarter ICAC minds started seeing use. It allowed a trained investigator or forensic technician to boot a suspect computer in a controlled manner to a GNU/Linux based operating system from a CD that ran entirely in RAM. We picked up the habit in Arkansas starting around 2005, but many investigators/technicians weren't very familiar with working with a Linux operating system and found it to be too complicated or challenging. Consequently we didn't see as much usage in the field as we would have liked.
While others, including the FBI, developed their own forensic preview tool, the next major milestone came from the National White Collar Crime Center (NW3C) in the form of TUX4N6. TUX4N6, like many others of that time, was also based on Knoppix, but the NW3C approach was to abstract away much of the complexity required of vanilla Knoppix. On boot, the investigator would be presented with a simple menu of choices to work through with everything being logged in the background. This tool largely became the method of choice across the nation for some years and all was well, until...
...the topic of volatile data came up. We asked, "What about evidence contained on live RAM that's lost when the power goes away?" There are volatile data artifacts other than RAM that we also lose, but that's how we came to the subject in the first place. Rebooting suspect computers, then controlled booting them into a forensic preview tool is a great solution to gain disk access but is deadly to volatile data. Clever developers and researchers began experimenting with new tools and methods to capture RAM data while the suspect computer was live and before a controlled boot solution was employed. Once the topic was off the ground, I even started hearing of defense attorneys accusing investigators on the stand of deliberately destroying potentially exculpatory material by not collecting volatile data at the time of seizure. Collecting volatile data, in fast, friendly, and forensically-sound ways, was still a few years off at that time.
Several tools do this now. Some are exclusive to law enforcement like osTriage while others are more widely available like FTK Imager. Most of these tools allow a variety of tasks to be performed while the investigator/technician is "in there" addressing other forms of volatile data besides RAM. Some of them seem to try to replace the controlled boot scenario altogether. Virtually all of them are accessed by GUI. The tools work great, and I have used/taught most of them.
So why bother with yet another forensic triage tool when there are plenty of stable and sound choices out there? The answer to that is more about paradigm than practice, I'll admit. Some years ago, I was introduced to a digital forensic paradigm then championed by Dell. I had been visited by some Dell engineers from Austin, Texas who were interested in experiments I was conducting at the time using a private cloud for distributed forensic processing with Ubuntu servers, Eucalyptus, and Elastic Compute Cloud (EC2). During their visit, they showed me a comprehensive digital forensic system that Dell had been fielding mostly in the UK. The key aspect was that the system was fully integrated - processes/examinations at every stage built upon the processes/examinations conducted at the previous stage. Hardware worked the same way in that new pieces added were instantly recognized and incorporated by the whole. This is more than simple plug-and-play. For example, the system made use of a portable storage device used together with a portable computing device to conduct onscene livebox and deadbox triage/preview. The portable storage device, when eventually transported back to the technician's lab and connected to a system workstation, would be instantly recognized and captured evidence automatically found. The system would then ingested the data into a new or existing case and processing could begin immediately. I fell in love with the idea on the spot.
The Dell system was out of my reach fiscally, especially considering I'd just spent upwards of half a million dollars for two server stacks for the distributed processing venture. The paradigm, however, could be applied to modified equipment I already had. The first test version was a rugged external hard drive with multiple partitions:
What is now CarnivoreLE started a few years ago as a way to address live and volatile data on a suspect machine without losing it when the power was eventually pulled away. To better explain why this was of interest to me, I'll take you back to 2001.
In 2001, I was assigned as a task force officer to one of the FBI's field division offices participating in their Innocent Images National Initiative - an investigative task force focused on Internet crimes against children and technology-facilitated child exploitation. We were trained in the common practice of pulling the plug on suspect computers that were found running during a search and transporting those computers to an FBI digital forensic lab for analysis. To even think of touching a keyboard or mouse while the system was live was punishable by death and dismemberment. Well, maybe not that, but it was still a strict no-no.
Later, after kicking off the Arkansas branch of the national Internet Crimes Against Children Task Force (ARICAC), the topic of forensically-sound previews had begun to circulate around digital investigation circles across the country, particularly at the national ICAC level. A version of Knoppix that had been customized and remastered by some of the smarter ICAC minds started seeing use. It allowed a trained investigator or forensic technician to boot a suspect computer in a controlled manner to a GNU/Linux based operating system from a CD that ran entirely in RAM. We picked up the habit in Arkansas starting around 2005, but many investigators/technicians weren't very familiar with working with a Linux operating system and found it to be too complicated or challenging. Consequently we didn't see as much usage in the field as we would have liked.
While others, including the FBI, developed their own forensic preview tool, the next major milestone came from the National White Collar Crime Center (NW3C) in the form of TUX4N6. TUX4N6, like many others of that time, was also based on Knoppix, but the NW3C approach was to abstract away much of the complexity required of vanilla Knoppix. On boot, the investigator would be presented with a simple menu of choices to work through with everything being logged in the background. This tool largely became the method of choice across the nation for some years and all was well, until...
...the topic of volatile data came up. We asked, "What about evidence contained on live RAM that's lost when the power goes away?" There are volatile data artifacts other than RAM that we also lose, but that's how we came to the subject in the first place. Rebooting suspect computers, then controlled booting them into a forensic preview tool is a great solution to gain disk access but is deadly to volatile data. Clever developers and researchers began experimenting with new tools and methods to capture RAM data while the suspect computer was live and before a controlled boot solution was employed. Once the topic was off the ground, I even started hearing of defense attorneys accusing investigators on the stand of deliberately destroying potentially exculpatory material by not collecting volatile data at the time of seizure. Collecting volatile data, in fast, friendly, and forensically-sound ways, was still a few years off at that time.
Several tools do this now. Some are exclusive to law enforcement like osTriage while others are more widely available like FTK Imager. Most of these tools allow a variety of tasks to be performed while the investigator/technician is "in there" addressing other forms of volatile data besides RAM. Some of them seem to try to replace the controlled boot scenario altogether. Virtually all of them are accessed by GUI. The tools work great, and I have used/taught most of them.
So why bother with yet another forensic triage tool when there are plenty of stable and sound choices out there? The answer to that is more about paradigm than practice, I'll admit. Some years ago, I was introduced to a digital forensic paradigm then championed by Dell. I had been visited by some Dell engineers from Austin, Texas who were interested in experiments I was conducting at the time using a private cloud for distributed forensic processing with Ubuntu servers, Eucalyptus, and Elastic Compute Cloud (EC2). During their visit, they showed me a comprehensive digital forensic system that Dell had been fielding mostly in the UK. The key aspect was that the system was fully integrated - processes/examinations at every stage built upon the processes/examinations conducted at the previous stage. Hardware worked the same way in that new pieces added were instantly recognized and incorporated by the whole. This is more than simple plug-and-play. For example, the system made use of a portable storage device used together with a portable computing device to conduct onscene livebox and deadbox triage/preview. The portable storage device, when eventually transported back to the technician's lab and connected to a system workstation, would be instantly recognized and captured evidence automatically found. The system would then ingested the data into a new or existing case and processing could begin immediately. I fell in love with the idea on the spot.
The Dell system was out of my reach fiscally, especially considering I'd just spent upwards of half a million dollars for two server stacks for the distributed processing venture. The paradigm, however, could be applied to modified equipment I already had. The first test version was a rugged external hard drive with multiple partitions:
- LIVEDISK partition = containing the deadbox OS, in this case TUX4N6.
- TOOLS partition = containing livebox tools, primarily osTriage.
- EVIDENCE = container for all evidence captures.
Lots of things were missing here. Primarily I had no backend system to integrate with as the distributed processing architecture I was working on wasn't finished yet. In fact, it would only finally be deployed a few months before I retired in 2017. I understand that they don't bother to even use it since I've been gone. What a shame, but I digress. No, it wasn't a manifestation of Dell's complete paradigm, but the idea didn't fade for me. The next version was essentially the same as the first, except I replaced TUX4N6 with PALADIN from Sumuri and added a lot more tools in the TOOLS partition.
I'll follow up on this in my next post with CarnivoreLE proper and show you where you can find it to try out.
Comments
Post a Comment