Timelines in P2P Forensic Cases
Creating a timeline of activity in a digital forensic (4n6) case can be vitally important to the ultimate goal of placing a person at the scene. In criminal 4n6 cases, the investigator, whether law enforcement or defense, is assigned the task to put a “butt in the seat”. This blog is intended to help avoid the many misconceptions seen regarding dates / times (DT) on reports from both sides. We’ve all spent countless hours gathering various artifacts and combining the data into a timeline. I’ve used my past mistakes and testing to help you avoid the same errors.
The sole intent of this blog is to help find the truth. Information and technology are continually changing. Please feel free to identify any incorrect conclusions or other errors on my part as I’m always excited to learn. Brett Shavers (Blog) and others have written about our innate need to solve problems and the processes we can employee. 4n6 investigators use information gathered from not only the digital device’s data, but from interviews, cell location, field investigator reports and other sources to achieve this goal.
The reason for identification of the “butt in the seat” for law enforcement is clear. The same need also applies to the defense. If the evidence shows that the defendant was at the keyboard, it is important that the client is made aware of the evidence against them. Taking a plea rather than risking an enhanced sentence by going to trial could be the best result for the defendant. There is also always the possibility that the defendant was not responsible.
Peer-to-Peer (P2P) programs are not as prevalent as they once were. Ares, eMule, Gigatribe, BitTorrent and others still show up in cases from time to time. There has been a vast resource of white papers, blogs and presentations on many of these programs and how to find and decode their respective artifacts. These resources are too plentiful to list here, but can be found easily with a Google search.
The examples, concepts and information in this blog will focus mainly on Ares P2P artifacts since it is fresh in my mind from a recent case. However, the concepts are applicable to most other P2P investigations and downloads.
The number one confusion I have seen in reports and that I myself have fallen into is the DT the P2P download was initiated. This specific artifact is critical when building a timeline of activity to compare with other activity found on the device. The Holy Grail is seeing a contraband download started near a person checking their personal webmail or using an identifiable login name into social media, shopping or other web site.
The problem, in my opinion, is the labeling used by most forensic tools when listing information carved from the P2P program’s database (DB). For example, when viewing Ares download artifacts, there will be column labeled “Downloaded Date/Time”. This is similarly named in multiple tools from IEF/AXIOM, EnCase Ares EnScript and other Ares DAT file descriptors. The label can be misleading to investigators that have not tested Ares or other P2P programs.
NOTE: This reinforces the mantra heard at every forensic training class I’ve ever attended. TEST YOUR RESULTS. You don’t have to be the world’s leading expert on NTFS or other file systems to perform simple DT testing.
The download DT in these DBs is actually when the download completed. The P2P programs record this information once the download has finished. Completed DTs are not useful for building timelines of activity for multiple reasons. P2P networks are notorious for being slow based on the availability of the file from multiple sources, the source’s bandwidth availability and most importantly if the source remains online. All these factors can cause a small MP3 file to take hours or days to complete. As seen in many cases, some files remain “incomplete” because the download source never reappeared.
The only reliable way to determine when the file download was initiated is based on the files Creation DT. To easily test this functionality, go to the Internet and download a file. Once it’s finished, check its Creation vs Modified dates from the file system. You will immediately note that the difference between the two will be the time it took your system to complete the download process. This same file system DT recording applies to P2P downloads as well.
Example Download using Chrome
The downloaded files created and modified DT showing it took 11 minutes to complete
Once you understand this relationship, the next thing that will become apparent is that the modified DT from the file system will match the “Downloaded Date / Time” from Ares DB.
This then means that the actual file downloaded will need to be located on the file system to obtain the creation DT to record the specific DT the file download was started. Don’t just look in the shared folder. The Recycle Bin is a great place to find these files as well. The Recycle Bin file artifacts will keep the original creation DT from the file when it was “deleted” by the user.
Example File from Recycle Bin Creation DT
21 jump street 2012 dvdrip latino xvid.avi
11/23/2012 11:43:10 AM
Sample Ares DB Record
As you can see, the video download took Ares over 10 hours to complete. That’s a big difference in time and can have a dramatic affect when building an activity timeline and comparing to other user activity on the system.
What if the downloaded file no longer exists? There are still some possibilities to at least narrow down the time the download was initiated. I had a case recently where a download was completed 30 minutes after Ares was installed. This would indicate that the download was started sometime between Ares install and the downloaded file’s completion. If there is no other information, all that can be determined is that sometime between the install of the P2P program and the files “Downloaded Date / Time”, the download process was started.
Another option is the incomplete download mentioned earlier. Ares and other P2P programs also track these files. The difference is that they track download started DT unlike completed files.
The important thing to remember is to interpret the data correctly when reporting on the evidence. No one enjoys having their findings called into question. However, I’ve found learning from mistakes is sometimes how I learn best.