Forensic Blogs

An aggregator for digital forensics blogs

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.

4.5_Touch2_Standard_01.jpg https://cf-media.cellebrite.com/wp-content/uploads/2017/07/4.5_Touch2_Standard_01.jpg

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.

Read the original at: The Leahy Center for Digital InvestigationFiled Under: Digital Forensics, Uncategorized Tagged With: Android, Blog Post, Champlain College, computer forensics, database, Digital forensics, email, Google, interns, kayak, map, Projects, Student Work, trips

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.

Read the original at: The Leahy Center for Digital InvestigationFiled Under: Digital Forensics, Uncategorized Tagged With: Blog Post, Champlain College, computer forensics, Digital forensics, interns, LCDI, Microsoft, nmap, Projects, Raspberry Pi, Student Work, vulscan, windows

About

This site aggregates posts from various digital forensics blogs. Feel free to take a look around, and make sure to visit the original sites.

  • Contact
  • Aggregated Sites

Suggest a Site

Know of a site we should add? Enter it below

Sending

Jump to Category

All content is copyright the respective author(s)