Forensic Blogs

An aggregator for digital forensics blogs

by

SANS FOR500 vs. FOR508

UPDATE: I am excited to announce that SANS FOR408 is now FOR500.  Over the last few years, we have continued to add more technical content to the class while ageing out some of the more basic material.  While the class still provides an excellent framework for conducting Windows forensic analysis, the course difficulty level has shifted to the SANS “5” level.  It gives us the freedom to teach some of the more complex forensic artifacts and techniques while still staying true to keeping it a “foundational” forensics course.  See for yourself: FOR500.pdf

Rob Lee put together a webcast discussing some of the class updates and changes: https://www.sans.org/webcasts/103377

With the major expansion of forensic curriculum at the SANS Institute, I frequently get questions about what class(es) to take. If you are trying to decide between FOR408 (Windows Forensics) and FOR508 (Advanced Forensics and Incident Response), this is the best comparison I have seen online.

I found the following quote particularly insightful: “508 is not a more advanced version of the 408, it’s a completely different course with completely different objectives.”

Digital Forensics Tips blog: A look at how the SANS computer forensics courses 408, 508 and 610 fit together |buff.ly/ZlZqwH #DFIR

— Chad Tilbury (@chadtilbury) May 23, 2013

by

Application Analysis: Conclusion

Introduction:

To close out our list of Web Apps, we finished up on Discord. It has been an interesting experience for us to work with the three diverse apps over the last semester. Our analysis on Discord brought our research to a close. Seeing several key similarities with our first application Slack, it was an ideal application to close out our research for the side by side comparison.

Our Process:

With our final app, we utilized similar testing methods to Slack; we created a set of Test Channels and generated user data. After that was done, our team made a clone of the Virtual Machine, then deleted Discord on the original and promptly analyzed the images. In our findings, we noticed very similar behavior in storage of cached images when compared with Slack, although the content they each stored varied greatly. To read more about this topic, check our report which will be published soon.

In comparison of these apps, Dropbox was the most straightforward. However, it lacked the robustness of the other Web Apps as it lacked the expansiveness of XML. The app did not change much from the front end in terms of design. For the User Data, Dropbox’s local sql database provided information of what files were found on the Machine, along with deleted files visible in the cache. In contrast, Slack and Discord were two sides of the same coin. They both featured a strong use of XML to manage their styles, and featured images of user profiles and stored the urls of certain cached images. Discord did end up having one major difference. We were able to find bits of the messages amongst Win7enterpriseTest1\C\Users\User\AppData\Roaming\discord\Cache in messages?limit=50. We’ll have a deeper indepth look at this in our final report.

Analysis: Discord Artifacts

Going into Discord, we expected to find close to nothing on the local files of the web application, but after getting a closer look, we found out we couldn’t be more wrong. Discord has a strong security statement stating that they take the reasonable steps to ensure a user’s information is protected.

Application

The uses of caching and SQLite formatting allowed us to recover artifacts such as the aforementioned chat logs to the images and files uploaded. Interestingly, one of Discords more interesting features is its database’s storage of frequently used Emojis. In comparison, the Business Web Applications tried to stick to the bare minimum and focus on the bare bones such as only having time stamps and ID values. Dropbox’s Local Database primarily focused on this with it having extensive storage on File information, though it was lacking in the niches of Discord, which, as mentioned before, even stored emoji usage. A more extensive comparison can be found in our Final Report.

Conclusion:

With increased integration of platforms such as Discord, Dropbox and Slack, there will be an increased need for privacy. Implementation without security will continue to allow various security flaws to exist. However, it must be remembered that with the need for Security comes the need of usability. To remain a strong web application with a following, an ease of use, and efficiency must be maintained.

Through the process, our group learned a lot and got deeper insights on Web App Forensics. We hope this Blog can hold you over before the final report drops. Stay tuned!

Questions or comments? Please share with us in the comment section below! You can also reach out to our Twitter and Facebook or email us at lcdi@champlain.edu.

The post Application Analysis: Conclusion appeared first on The Leahy Center for Digital Investigation.

by

Bluetooth Security Forensics Conclusion

Bluetooth Introduction 

The Bluetooth Team has been working hard all semester and has finally finished testing with all bluetooth tools. This semester has been challenging for everyone as we learned about Bluetooth and its vulnerabilities. Our team has gained a lot of insight into the realities of modern Bluetooth security, using tools such as Econocom Digital Security’s  Btlejuice, Pwnie Express’s BlueHydra, and the L2ping command within the Linux Bluez library.

Btlejuice Conclusion

Using Btlejuice had many difficult hurdles to overcome when working with it. The goal of using Btlejuice was to be able to intercept bluetooth packets (specifically GATTs) when it was being broadcast, and be able to use that information to control the bluetooth device. Some of the problems we faced as a team was Btlejuice did not working well with Firefox. It had trouble picking up devices consistently. The creator of Btlejuice, Damien Caquil, stated that it works best with Chrome. We tried installing Chrome but we were not able to install it onto our Kali distribution, so we had to resort to Chromium, which unfortunately did not fix our connection problems either.

Bluetooth

Figure 1: Network diagram of the actual configuration the team encountered

Figure 1 above is a diagram of the setup we had when using Btlejuice. The proxy is facilitating the Bluetooth connections and the web proxy is supposed to view the intercepted data. The problem we encountered (see letter A) was when our Schlage Smart Sense Lock was connected to the proxy was that the proxy would not relay back to the iPad and thus no information could be intercepted coming from the iPad. We have also demonstrated that the Smart Sense Lock will not send data to the proxy if it’s locked or unlocked status as evidenced by the fact that even when using the keypad or the turn lever to open the lock we did not intercept that information.

Bluetooth

Figure 2: Network diagram of the ideal configuration

In the above Figure 2, one can see the ideal process by which the proxy is supposed to work. It acts as a relay and any commands going to or from the controller or device will be intercepted by the proxy, captured, and then sent on to its destination. Letter A shows how the proxy is relaying information back and forth to both devices while letter B shows that the hci0 device is connected to the Smart Lock itself.

BlueHydra Conclusion

Initially, we wanted to use Bluehydra to find information about bluetooth devices in the area. Specifically, we wanted to determine the range of each device in an attempt to potentially track an individual around a building based on the location of their Bluetooth device. However, the team was never able to get this feature of BlueHydra to work. Conversely, the team was able to get important information on visible devices such as their MAC address, device name, Bluetooth version, and the device manufacturer. It was vital to obtain this information about our Bluetooth devices so that we could exploit them using the other tools in our vulnerability assessment repertoire, such as Btlejuice and L2Ping.

L2ping Conclusion

We first discovered L2ping as a means of detecting if a device was transmitting so we could begin testing. We discovered “Bluesmack”, the term used to describe the malicious use of L2ping command, shortly after and began testing its effectiveness against devices ranging from bluetooth keyboards to a Macbook Pro. Our testing revealed that L2ping’s effectiveness was varied in terms of the devices it could be used against. L2ping could completely shut down a smartwatch or keyboard, but in turn, could not cause any noticeable disruption to a larger device such as a laptop.

Questions or comments? Please share with us in the comment section below! You can also reach out to our Twitter and Facebook or email us at lcdi@champlain.edu.

The post Bluetooth Security Forensics Conclusion appeared first on The Leahy Center for Digital Investigation.