computer forensics Archives

November 15, 2018 by LCDI

Mobile App Forensics: Travel Apps

Introduction

What kinds of information can be found on applications such as Kayak and Google Trips? This project involves analyzing mobile travel apps installed on android-based devices. Our goal is to analyze these applications using UFED Cellebrite in order to give forensic analysts good information on what to look for when extracting data from these applications.

Findings

Using UFED’s Cellebrite 4PC and Physical Analyzer, we found user-generated data from the internal storage of two phones and tablets. Our team chose to use two Huawei H1511 Nexus 6P’s and two Nexus K009 7’s. Each team member wiped their devices, installed the travel app on their mobile devices, and logged in to said app with their fake Gmail account. Then each member then created a new trip from Burlington to Montreal for a particular date. We created Watchlists with flights, car rentals, etc.

After we generated bits of data on the devices, we would take Physical Extractions of each device. Most data considered to be useful we found to be in the form of .sql files (database files). Our team found the database files containing information like the company of the airline ticket we Watchlisted, the model/make/price of the rental car we searched for, the user’s email and username, and the timestamps for trips created by user.

Cellebrite.com

Conclusion

For our next steps, we will be using UFED Cellebrite to analyze more applications such as Google Trips. Our team will use the information found that’s extracted from Google Trips, we plan to take a closer look at what artifacts are important for forensic analysts when extracting data from these applications. Stay tuned for updates by checking out @champforensicslcdi on Instagram and @ChampForensics on Twitter!

The post Mobile App Forensics: Travel Apps appeared first on The Leahy Center for Digital Investigation.

November 15, 2018 by LCDI

Windows IoT, Vulscan, and Other Problematic Programs

Introduction

Last time we touched base, we described our journey into starting our work at the LCDI and our growth as interns, as well as some of the things we learned so far. Today, however, we wanted to touch on a different subject. Many forget that the mistakes, accidents, hiccups, and small failures of any project are just as important as the successes. Sometimes they’re more important as their lessons are greater than those you learn miraculously getting something right the first try. Although we’d like you to think we’re hyper-intelligent computer networking wizards who are ahead of the game, we aren’t. We have made some blunders, a decent number of errors, and a handful of happy accidents on this quest—but we are all the better for it.

“I have some choice words for Windows IoT”

The first scans we ran were on a small network of Raspberry Pis which were all running different services. One of these services was a Windows machine, and the unexpected hassle of setting up such a device was grueling. The only Windows OS “optimized” to work on a Pi is Windows IoT Core, which is Microsoft’s crack at a lightweight Internet of Things (IoT) operating system. If you’ve never heard of it, it’s probably because Microsoft would rather not advertise it. The service is free to download, but is not, in fact, designed optimally.

After first burning Windows IoT to a microSD, we plugged the SD into the Pi and turned it on. Windows IoT failed to boot, not once, not twice, but so many times we lost count. Even after we followed instructions step-by-step from both Microsoft and other websites, it refused to cooperate. After about two hours of attempting to boot Windows IoT, reburning it to the SD, trying a different SD, and failing some more, Windows IoT booted successfully without us doing anything differently the next day.

Once we logged onto Windows IoT, we needed to set it up to work with SSH so that we could input commands to it from our workstations. We didn’t need Windows IoT for anything specific, we just needed some sort of Windows machine to secure a connection to. However, getting Windows IoT to establish SSH connections required another three hours of trial, error, and scratching heads. Finally, we turned the machine off, reburned the SD with another fresh copy of Windows IoT, turned it on, and lo and behold, it worked—again without us doing anything differently. This worked for about a week until one day, the password and SSH key randomly changed during a scan cycle.

The palpable frustration we experienced as a team cannot be understated. But the moral of the story is keep working at it. We didn’t necessarily have to use Windows IoT. In fact, we would have preferred we didn’t, after the problems it caused. But we got it to work, and that’s what really counts.

What’s the deal with Vulscan?

Vulscan is a plugin for Nmap that adds vulnerability database checking functionality. It’s designed to take advantage of Nmap (which, if you remember from last time, is the software we’re using to scan the network) and its more invasive functions to diagnose potential problems that may occur with the machine automatically. This service was the thing we were looking for; without it, a person would have to diagnose all vulnerabilities by looking at our reports, which are sometimes very long, and may not provide all the necessary information.

We set up Vulscan early, but ran into problems as it didn’t run due to how we set up Nmap. Once we figured out our mistake and got Vulscan working, it became clear that the script was not optimized. Because it uses Nmap’s scripts for parsing potential vulnerabilities, the best Vulscan can do is guess what vulnerabilities are present. And it will give you every single guess it has, even the ones it knows aren’t likely to be true.

This headache was compounded when we learned that Vulscan would not run in our own script. It turned out we were actually using a slightly different version of Nmap, called libNmap. This version of Nmap is designed to run in a Python script which meant Vulscan didn’t recognize it as Nmap. So, our choice was to either scrap the completed script we made, which worked as intended, putting us at least a week or two behind, or abandon Vulscan and stick with what we had.

Ultimately, we decided to ditch Vulscan rather than sacrifice the valuable time spent on our script. Although it contradicts the last anecdote, sometimes it’s better to cut your losses and stick with what works rather than fix what’s broken.

Conclusion

Now, I know that these stories may leave the reader on a sour note, and that was somewhat intentional. Our team experienced these major frustrations and it helps to understand them for the reasons I described above. I hope that if people in the future ever try to replicate this project, they heed the advice presented here.

To learn more about this and other blogs of the LCDI visit us here: LCDI Blog.

Stay in the loop on our current and upcoming projects and events by following us on Facebook, Twitter, or Instagram.

The post Windows IoT, Vulscan, and Other Problematic Programs appeared first on The Leahy Center for Digital Investigation.

October 30, 2018 by LCDI

Encase Tool Evaluation

Introduction:

Over the past five weeks we have been researching and gathering information on Opentext software EnCase 8, readying ourselves to begin dissecting evidence in our mock investigation. As the EnCase 8 intern team, we have been spending large amounts of time watching YouTube videos and diving deep into the manual provided by Opentext software. Most recently, we have spent time running through our mock story, completing final checks of the data generation and finally starting our data generation in the VM. We are a team of two first year interns trying to get our foot in the door of the digital forensic world. This is our story….

Our Story:

Since day one, we have been slowly figuring out the ins and outs of EnCase 8 and its usability in our investigation. Hours have been spent watching “how to” videos and trying to replicate the actions in EnCase on a flash drive full of files. We have also been doing a heavy amount of reading from the manual, taking notes, and highlighting important commands that will become necessary when using EnCase. One of the main features we needed to know how to do first was imaging drives. To learn how to image a drive, we used a write blocker hooked up to a hard drive and then we followed our notes to image the drive. This was just one of the many important features we will be using with Encase.

Upon completion of our never ending quest to better understand EnCase, we begin to familiarize ourselves with the story we generated as a team of 8 that we’d be using for our investigation. This involved reading through the story day by day and testing the actions from the script that we wrote. Once this was all completed, our team member Matt was the first to run the final data generation in the VM for the first time. He started with opening the tool evaluation VM and began to work his way through the day one script for our mock investigation. Matt followed the script closely while taking detailed notes of anything he added to the script to beef up day one of our data generation. He also took detailed notes on what was displayed on the screen including the time and action that occurred.

Conclusion:

Next up, we will begin to use EnCase by doing keyword searches and gathering artifacts.We are very excited to get our hands on the mock evidence and truly begin our professional digital forensic experience. Expect us to slowly but surely harness the powers of EnCase 8 and dive head first into this investigation evaluating Encase as we go. We will take detailed notes and begin the process of compiling our report on EnCase 8. Stay tuned to hear more about our ups, downs, and everything in between here at the Leahy Center for Digital Investigation. Check in on Instagram @champforensicslcdi and Twitter @ChampForensics!

To learn more about this and other blogs of the LCDI visit us here: LCDI Blog.

Stay in the loop on our current and upcoming projects and events by following us on Facebook, Twitter, or Instagram.

The post Encase Tool Evaluation appeared first on The Leahy Center for Digital Investigation.