In the last post, we discussed a number of valuable Google account artifacts that are not necessarily captured in a Google Takeout. One of the these, the Google Activity Log, is a unified timeline containing cards for various Google services associated with the account. Chief among these artifacts were Chrome internet history, Android application usage, and audio recordings of the user interacting with Google Assistant or Google Home products. While this information can be queried and filtered online with access to the account, what can we do to collect this information offline to review at a later date? Here’s one solution.
It is no secret that many tech companies, including Google, collect an inordinate amount of data about their users. It make sense, knowing it’s userbase is Google’s core business and allows them to more effectively serve customers and enhance their service offerings. Where then is all of that information and how, as investigators, can we access it? When it comes to preserving Google accounts, most begin and end their investigation with Google’s Takeout feature. While Takeout is indeed a great and useful tool, it isn’t the only option we have when it comes to collecting data associated with Google accounts.
Most everyone has a nearing-out-of-control abundance of webmail and social media accounts. What happens when we are asked to preserve all of these accounts? Webmail is easy enough, there are plenty of tools, notably Outlook itself, to sync email. But what about social media data like Facebook or Twitter? There are a few tools out there, such as X1 Social Discovery, which can support these types of collection efforts as well. Thankfully some of these services offer users a way to download their data themselves. Four such “native backup” solutions are discussed below.
With Python Digital Forensics Cookbook officially out the door for some time now, I have rediscovered time to work on projects, including this one. With the book wrapping up successfully, I intend to rededicate myself back to bi-weekly posts and instructionals on various forensic topics. In this post, we will go over some new additions to the Go Phishing script introduced here a few months ago. The code can be found on the PST-Go-Phish Github repository. Join me on the development journey as we create a phishing discovery tool from scratch. Let’s get started!
Picking up where the last post left off, we are going to add some additional functionality to the previous Go Phish script. As discussed at the end of the previous post, another common tactic used in phishing campaigns are one use throwaway email accounts. In these scenarios, the goal is not to impersonate a trusted contact, but rather send an email as an unknown contact which may better slip through the cracks and get someone to click on link or attachment. In the post, we add functionality to alert on one-off emails potentially coming from throwaway email accounts. This is a useful category of emails to review in triage scenarios and typically comprise of only a few emails matching our criteria.
With 2017 in full swing, the ever-maligned and down on his luck Nigerian Prince is as hard at work as ever. While tried and true, phishing scams have continued to evolve with the times even if the underlying method to carry out the scam is the same. What’s one to do other than review emails for bad punctuation, suspicious attachments, and ludicrous scenarios?
Hard drives have been the gold standard in storage medium for a very long time. However, that isn’t to say they are without faults or are not susceptible to damage or data loss. When these drives do fail, and if there are no available backups, this can come with grave consequences. This is especially true when the drive is of great evidentiary value or contain many hours of work product. Either way, shrugging your shoulders over the loss is not always acceptable. There are a number of potential factors that could have caused the drive failure. In this blog post, we will take a look at the easiest and least invasive repair we could attempt – swapping the drive PCB.
I have been hard at work the last few months developing code and writing chapters for my latest book with Chapin Bryce titled Python Digital Forensics Cookbook. Because of this, I must admit I have no new content to post to the blog this week. Instead, I am taking this as an opportunity to elicit feedback and suggestions. In exchange for that, I will be giving away eBook copies of my first book, Learning Python for Forensics, to two randomly chosen individuals.
The Spotlight series highlights useful Python libraries and their forensic application.
You’re no doubt aware that major technology companies, like our great benefactor Google, retain a great deal of data regarding their users. It shouldn’t come as much of a surprise considering how important users are to a company’s livelihood. Wouldn’t you want to know, if you could, every detail about your customers and who you do business with to better engage them? And as disturbing as that can be (have you seen Google’s location history timeline?), I think we can all agree that we have wished for similar omniscient-like knowledge in our investigations. I hate to disappoint you, but this isn’t a post about that.
One thing that can give us the appearance of omniscience is a history of the user’s whereabouts. It can be hard, for example, to discount a mobile device’s reported location at the scene of the crime at the time the crime occurred when the user’s alibi places them a few towns over during that same time. In this day and age who do you think you are fooling with the “My phone wasn’t with me” gimmick.
What happens when you receive or take custody of evidence that ends up being non-functional? Without the right tools and training, the answer might be nothing. Perhaps the owner purposely tried to damage the device or it is due to some internal malfunction. Either way, data on these devices can be of great evidentiary value that proves or disproves previously held conclusions. And while there are an ever-growing number of data recovery shops, their services can be costly and may introduce significant lag time to a case.
Whether it is due to budget or time constraints, it may be worthwhile to assess the situation yourself (after getting permission from the appropriate authorities, of course). When it comes to USBs, we will discuss a few methods we can use to extract data from the broken device. Please be aware the methods we will discuss involve using high heat to separate the memory chip from the USB logic board. It is possible to further, and even irreparably, damage the device this way. Practice, as always, is key.