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

Automated Network Scanning + Final Experience

With our time here and finals week approaching fast, we are working to tie up all loose ends. Our final report is now complete, and we’ve done as much as we can with our scanner. The script scans the network, prints out some information, and sends it to an email address. We only got around to collecting the ports and services hosted on the network. If we had more time, we would have added more features, like OS detection or complete automation. As it is, we only managed to get the basics complete in time.

 

This is due to both a lack of time, and the many obstacles encountered throughout the course and scan of our project. If we had started with more experience, we would have been able to finish much more than we did. We spent a good amount of time figuring out how to actually use the tools instead of working on the project itself. In the end, we were unable to do as much as the other teams. Naturally, we are now much more experienced than we were at the start. Our work here at the LCDI has taught us a lot, and it has been a very positive experience for both of us.

 

Moving forwards, our primary goal is to wrap up last-minute objectives. First among these will be editing our final report once the Tech Writers have reviewed it for more time. This will more than likely take up our final shifts. Once we’ve completed this task, we will be all but done with our project.

The post Automated Network Scanning + Final Experience 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.