Forensic Blogs

An aggregator for digital forensics blogs

by

Mobile App Intern Final Blog Post

Project Wrap Up

The Mobile App Intern team chose 3 travel apps to analyze. Kayak, Expedia, and Google Trips. All three apps stored their data within the internal storage of each device it was downloaded onto. However, Expedia proved to show very little artifacts that could be useful for forensic analysts. Most of the data kept by Expedia is not data meant for the user or analysts’; it is meant for the app itself (data logs etc). Google Trips saved the most user data out of all three of the apps. It kept user info (username and password hash), trip details (title, locations, etc), and location data. Kayak mainly stored location data, the names of hotels, and rental company information. For example, if one were to use Kayak in order to rent a Mercedes-Benz for $60 USD a day, they can set what dates to rent said car and Kayak will keep all of that information about the car and company stored. The same was true for plane and bus tickets. Company, price, dates of departure/arrival, and user timestamps are all stored.

Final Thoughts

The Mobile App Intern Team is grateful to the LCDI to have been given the chance to utilize their devices in order to perform projects and research. The team was able to acquire new skills (like rooting Android devices) and read many useful journal articles relating to mobile forensics. 

The post Mobile App Intern Final Blog Post appeared first on The Leahy Center for Digital Investigation.

by

SIFT Update 3

Introduction

As we are coming to an end working at the Senator Leahy Center for Digital Investigation, we are closer to completing our final report. Our last post was about recovering artifacts and keyword searches. Due to time issues and inexperience, our team couldn’t recover deleted files.

Experience

Throughout the semester, working at the LCDI with the SIFT-workstation has been a refreshing challenge. Coming into the Center has always been a fun and engaging experience. We’ve learned vital information, especially in regards to digital forensics. We’ve even been exposed to the Linux Command Line.

Researching the SIFT-workstation from SANS  also exposed us to quite a bit of information about SANS. The more we have learned, the more we have realized how exciting the digital forensics field can be. From a first year student’s perspective, technical jargon and new information can be daunting. With the amount of easy-to-read information that SANS has put out, our team agrees that learning becomes simpler.

In regards to the Linux Command Line, our team was subjected to the experience of learning syntax, system commands, and other programs. Both my partner and I have heard from our professors that these skills are integral as investigators. Having that experience is important to us as aspiring students.

Since we are nearing the end of our time on this project, our team has focused on learning how to generate timelines and search clusters. We’ve also looked into bulk extraction and learned that these are typical and required tasks in this field.

Conclusion

In the end, our experience at the LCDI has been overwhelmingly positive and beneficial. We were exposed to and learned from largely important topics which is an opportunity we’ll always be grateful for. Although our team didn’t meet every expectation we had, we still experienced much more than we expected out of the internship.

The post SIFT Update 3 appeared first on The Leahy Center for Digital Investigation.

by

Automated Network Scanning % Success Over Error

Network Scanning Wrap Up Now That We’re Done

Welcome to the final installment of the Automated Network Scanning % team’s official blog. Our project is now over. The final tweaks are being made to our script, our scans are all shut down, and our team is beginning to finish their internship hours. A lot has happened since our last blog. We spent the majority of November running our scanner against different targets. The results we received from these scans were helpful in deciding what changes to make to our script. Despite our progress made on the scanner, there are a few things we could have done to make it better, if time permitted.

Testing Our Scanner

To test our scanner, our team used a combination of our VM, Pi, Pi network, and LCDI network. We began by targeting our Pi network that we made last month. First by running our scan on the VM. Then we believed that the superior power of the VM would make the scan run faster. Once we confirmed this, we would use our Pi scanner on the network. Our first scan was a smashing success. We used our VM to scan our pi network and it found all the servers we installed on the Pis. Now that we knew our script worked, we scaled up by testing our scan against the LCDI network.

The LCDI network scan performed without any errors. Our only issue was that it took too long. We made some improvements to the script that we believed would speed it up and then reran our test. This time the script worked much faster. This gave us much more confidence in our script, so we moved onto scanning off of our pi. As predicted, this scan was slower than the previous, but not beyond the realm of useable.

Error again

At this stage we decided to make another improvement to our scanner. We wanted to make our Pi run the script for the scan on boot. This meant that as the Pi was turning on ,it would automatically run our scanner. This process turned out to be more difficult than we thought, but eventually we got it working. In the meantime, we ran two more scans of the LCDI network that also worked. After these tests, the team felt comfortable to say our scanner worked without error.

Test results

The results that our scanner got were exactly what we were hoping to get. The first scan of the Pi network finished in 19.05 seconds. The scan found our ssh server, our http server, and both of the ports needed for our file server. We reran this scan to confirm our results and found that indeed our script worked. We then moved on to scanning the LCDI network. Our first scan of the LCDI network took 4 hours 25 minutes and 48 seconds. After adding our improvements, the scan only took 2 hours 28 minutes and 48 seconds. The three scans we did from the Pi averaged out to taking 3 hours 58 minutes and 48 seconds. This met our goal of being under four hours for a scan.

The picture above is a screenshot of the results from our third scan. The host IP’s and MAC addresses have been removed for security purposes. Using our scan results, we were able to identify multiple things about the LCDI network. The first thing we saw was the locations of both of the LCDI subnet’s. We also found a few IP’s that are up but not running any services.

What else could be done

The team is very happy with the work we have done here at the LCDI, but if we had some more time there are a few things that we would have improved. First, we would attempt to make the scanner faster. We met our goal of being under four hours, but we could still do better. We have some ideas of how to do this, like splitting the IP’s up into smaller groups and scanning these groups. Another improvement we would’ve liked to make was automatically identifying aspects of a targeted network. We could have coded in a function into our script that automatically identified subnets based off of our scan results. We also could have a function that identified IP’s that are up but not running any services, and give reasons as to why this is happening.

However, over all, our project was completed successfully.

The post Automated Network Scanning % Success Over Error appeared first on The Leahy Center for Digital Investigation.