Red Team Village - Enumerating Cloud File Storage Gems
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Wylie, Michael
Organizational data is rapidly moving to the cloud, but it's not always intentional. The shift from on-premise data storage to the cloud constitutes a significant challenge and risk to the modern enterprise. The use of cloud file storage applications is on the rise for both consumer and business systems, which results in interesting data and metadata siting on endpoints. In this talk, we'll examine the large footprints of popular cloud file storage applications such as OneDrive and Box - learning what information can be enumerated from each cloud file storage solution. In some scenarios, data can be carved out from cache, restoring sensitive documents no longer on an endpoint.
 Cloud File Storage Gems. I'm Michael Wiley, Director of Cybersecurity Services at Richie Mae Technology Solutions. Prior to joining the firm, I owned a boutique cybersecurity firm in Los Angeles, California, where I performed penetration tests, red team engagements, fishing campaigns, social engineering, and so on. These days to do a bit more around compliance, digital forensics, instant response, and security architecture. I've got plenty of certifications I've collected over the past few years, and I enjoy what I do tremendously. I encourage you to connect on LinkedIn and follow me on Twitter. Those are probably the best two ways to get ahold of me after this talk. About Richie Mae. Well, the firm was founded 30, going on 35 years ago as a tax and audit firm. A while ago, transitioned into business advisory, and during that process, the firm realized that they wanted to advise their clients on technology and cybersecurity. They brought in my boss, who's a former CISO. They acquired my firm and a couple of others to build the team that I work with today. I focus on the media entertainment industry, while the firm's other niche is the financial sector. So I get to work with a lot of studios and vendors that make the movies you love happen. Some of the learning objectives we're gonna go over in this talk. We're gonna learn what file artifacts are available in cloud file storage applications. We'll see what kind of cloud file storage user activities we can enumerate during a penetration test. We'll be introduced to application logs and what's available there, and examine the difference between cloud file storage providers. So first, I wanted to give some credit where credit is due. Some of this I have come up with from my own testing, from forensic cases that I've looked at, as well as a lot of reading from other people's work. So just name a few of those who have created content and things that I have read, come across, looked at their research labs, et cetera. These people are due credit. So why are we talking about cloud file storage solutions? Well, back in the day, obviously we had file servers on-premise, and that's the, most of the time, the crown jewels, what we're looking at during that test. It could be obviously a database or something else, but a lot of times you're gonna find those GC gems on a file server. These days, we seem to be doing it rich in May. A lot of migrations helping customers move away from the traditional model of non-premise file server and trying to utilize some of these cloud file storage solutions like Box, Google Drive, OneDrive, Dropbox, Sharefile, et cetera. And so some of the perceived benefits that organizations get to this and why they're making that transition is that, one, there's protection against disasters, for the most part, right? So whether it's the pandemic, you can go home and obviously access Google Drive, whereas if you had a file server on-premise, you'd have to be VPN access or some other way to get to those files. There's a decrease in maintenance. So IT departments don't have to sit there and patch file servers. They don't have to work on ACLs. They don't have to troubleshoot DFS issues, sync problems, all those kind of things. There's also the perceived high availability aspect of it. Sure, cloud can go down from time to time, but for the most part, these cloud file storage solutions are having uptime higher than file servers that are sitting on-premise. They're also scalable. So Google will happily sell you an extra terabyte or two terabytes of space with just an increase in your price of your monthly subscription. Whereas if you have a traditional file server on-premise and you're running out of space, you may have to add hard drives to a RAID cluster or add systems to a cluster or whatever mechanism you're using to get more space. It's also, there's some ease of management, right? You don't have to get into a Windows operating system and adjust file permissions or folder permissions or share permissions. You can just basically make a couple of changes from a web interface. There are a couple of uses that we're gonna take a look at. And so if you do end up compromising a system and you suspect or see that there was a cloud file storage solution there, you may run into one or two scenarios. One, it may be business authorized. So there may be a cloud file storage solution that the business has paid for, implemented and deployed. And there may be some differences than if you find the application installed, but it's a personal account that they have logged in with. So in many cases, I've gone in from both perspectives, offensive or defensive, and we have seen applications installed that were not sanctioned by the organization, but it was either a employee who thought they were doing good or they wanted to just access their files and they downloaded Dropbox or Box or some application and started syncing files. So what are those different solutions out there? Well, we're gonna talk about Microsoft OneDrive, Google Drive, Dropbox, Box and Citrix ShareFile. And the data here was pulled up from, I believe it was SolarWinds did a study on this and they outlined small, mid-size or large businesses and which solution they're using. So you can obviously see Microsoft OneDrive, it's baked into Windows 8 and above, so a lot of people are using it, but when you start getting to some of the other solutions like Box, you can obviously see they're focusing on larger businesses in that market share. So there's, as I mentioned, there's two different scenarios that we might run across. One is where the remote system that we've compromised, it's they're running a cloud file storage solution that is sanctioned by the corporate environment. And in that case, there may be CASB or off-site logs or other security controls where they're monitoring or controlling what's going on. But we may run across the other scenario on the right-hand side there, where there's the sanctioned cloud applications that may have CASB that is not in line or other security controls, but they're also using a personal version of Google Drive or OneDrive or something like that. And that may bypass some of those shadow IT or security controls that the defenders put in place. So what are some of these gems that we may uncover as we see that there is a cloud file storage application on a system we've compromised and what can we get from that? Well, if you think of cloud file storage solutions as replacements of file servers, we may see customer data, financials, employee data, HR. You wouldn't believe some of the things that I have seen people store in cloud file storage solutions and with laxed security around them. Some of the things that these cloud file storage applications may leave behind that of interest to us, cached files. So whether those files are stored on the cloud or local or local, but then they were deleted, we see, we may be able to recover these cached files and actually see or recreate some of those files. We may see the local files, we'll get a database with all the files that are stored locally, but more importantly in the cloud as well. So we can see what is out there that maybe the user doesn't have stored locally. We'll see file usage and their behavior around those files, what files they're accessing most frequently. We'll be able to find traces of possibly deleted files as well. So as I mentioned, there is either a business or enterprise account and that may be company issued. There may be additional logging and security controls that the security team or RT team has, such as CASB. There's also more logging generally in the cloud if it is a business or enterprise account. Whereas if you stumble upon a free account that someone has on a system you've compromised, it may not be company issued, so there may be no knowledge of it. There may be no access to the actual account itself. That may be not synced with Active Directory or LDAP or single sign-on. So we may not be able to gain access to that right away. There's no central visibility by the defenders though. So they're not gonna see the things we're poking around or accessing. And then we're also gonna be able to find some local logs there. And so the difference between those business enterprise accounts and the personal free accounts is that there's a lot more storage with the business accounts that are built in obviously depends on what you're paying for. But you might have G Suite, the equivalent to a personal account would be Google Drive. It's not exactly called that, we'll get into that in a second, but 15 gigs of free space there. So even if it's not a sanctioned account and someone just installs the Google Drive app, you can have up to 15 gigs of gems as you can find there. With Officer 65, it comes with OneDrive subscription there. OneDrive basics, the free alternative with only five gigs, Box, Business, or Enterprise. You can have different levels of storage, but you can also get two gigs of free storage with a basic account. Dropbox Pro, the equivalent for a free account is Box Starter. This may have changed since I built this slide a while back. It used to be able to get about 100 gigs of space. I think they have limited that. So let's talk about Microsoft of OneDrive first. Let's get into it. That's the one that's baked into Windows 8 and above. It must be enabled. So it's installed, but you need to enable it via authentication. So once you sign in, it does a couple of things. Add some registry keys as well as it creates the OneDrive directory sitting in app data, local, Microsoft. So that folder will not be there. That directory will not be there until you authenticate with the OneDrive application. Now, if you have a personal account, you're gonna see within app data, local, Microsoft OneDrive logs, you're gonna see a personal folder directory. If they have a business version of OneDrive, you're gonna see business one. Now, I believe the reason they do business one is because that you can install or sign into more than one account. And so you might see business one, business two, business three, but the primary account should be business one. With Office 365, the defenders do have a unified logging. And it is by default enabled from my recollection up to 90 days. Now, from the instance I've been working more recently, and what we see with some of the like the Mandiant dwell times and Verizon DBI reports and whatnot, is that our dwell time is getting better, but it's still pretty long. And so that 90 days of retention may not be enough for the defenders to see what's going on, especially in the red team engagement. So, but even with a personal account though, there's no central logging from what I can see on the web interface of OneDrive. So all those logs are stored locally. And obviously maybe you can subpoena Microsoft or get whatever logs they have, but at least from the availability for IT and security professionals who are trying to investigate what might have happened or who access this, it's a bit limited. Right, and so on the left hand side there, we can see in app data, local Microsoft OneDrive logs. We've got a couple of different logs that are stored locally on the endpoint. And on the right hand side, we see the business unified logs. So a couple of interesting directories and folders that I've outlined here for you, is that some of the things we can see if we've gained access to a system that is syncing with OneDrive is that the user profile slash OneDrive is the default data store of where things are gonna go. If it is a Office 365 business account, it'll be OneDrive dash and the company name. So we'll be able to see what company they work for as well and make sure it's obviously in scope. The, we'll then see the root directory within the logs directory, which is kind of strange. We'll also be able to see some metadata for local and cloud files. So even if the file is not synced locally, we may be able to see it in the sync diagnostics log. There is a big maybe there I'll talk about in a second. And then we're gonna have a, a dat and in i file. And those two files, it's going to start the, the actual file name is gonna be the customer ID or the CID of the user. So you'll see with the CID.dat, you'll see a list of local and cloud file names. So even things that are not synced locally, you'll be able to see those. And the CID.ini file will be able to see the file store locations and sync time usage details and some other metadata there. We're gonna see another file that starts with the CID of the user, followed by a dash and profiles service response.txt. That will give us the name, email, CID, email, phone and title, et cetera of the user. That only is the case though for personal accounts. When I tried it with Office 365 or paid versions, I did not get this file. I find that interesting because most people aren't gonna sign in or add their title and phone number and address and stuff like that. I'll show you a more detailed version in a second here. And most of the time you're gonna see that as null, but at least you can see the email address that they have associated with OneDrive. And then you're gonna also find a obfuscation string map.txt file. And that's gonna be important to map back to obfuscated file names. And I'll show you how that works in a second too. So within the syncdiagnostics.log file, I have observed two different types of files, right? And so you may get one of two versions. And I think I've narrowed it down, but I haven't had enough test cases to verify this. I'm gonna call one the summary syncdiagnostics file, and the other one I'm gonna call the details syncdiagnostics file. And now what I've noticed is that if I install Office 365 OneDrive and I look at the syncdiagnostics file, I keep getting the summary version. And, but if I try a personal version and I've tried multiple labs and syncing it, what I've generally seen is that the first machine you activate OneDrive on will have the detailed syncdiagnostics.log file. And then every subsequent system you sync with will have the summary version. So that's my theory at this point. Again, I need more testing for that. And I'll show you what those look like. So on the left-hand side here, we've got the detailed syncdiagnostics.log. And you could see that there's, in the bottom part of that, there's files and folders that are presumably added or synced. And you could see some type of mount point with possibly a grid. And then there is a backslash. And then a three-word string. So far jump, sue, sue back, egg, and so on. So those are obfuscated file names. And I'll show you how to decode those in a second. On the right-hand side, you have the summary version of the syncdiagnostics file. It's not as verbose. You have statistical data, you know, sync progress. You've got last sync time, bytes downloaded, bytes uploaded, that kind of stuff. And so here's again, a little bit more of the summary version, where you could see the number of changed folders, deleted folders. It's really high-level information there. Now, if you happen to get that detailed version of the syncdiagnostics.log, what you can go ahead and do is, obviously we don't know what C bat egg is, but you can go ahead and open up that obfuscation string map. And again, all of these files that I'm talking about, with the exception of Dropbox, they are all clear text. So these files, it's not something special I've had to open up. The obfuscation string map is just sitting in a directory that anyone can access. And when we look at the syncdiagnostics, we're gonna have to take that three-word string there, like C bat egg, and we're gonna have to go map that to our obfuscation string map text file. And so there we can see that C bat egg essentially equals the desktop. So it looks like a folder was added to sync, and that folder was desktop, right? So it's a little bit of work, but you can go ahead and map those back and forth there. Just a little bit more on that obfuscation string map text file. I think that last slide showed it in great detail. Okay, and then so the CID of the user.dat, if we open that up, that's gonna show us the list of file names both locally and in the cloud. So even if it's not synced to the local file system, we could see what that user has access to in the cloud. And it is a little bit challenging to read this dat file. It's not formatted in the greatest way. So you can open it up in a hex editor, and you can even see, you know, searching for strings isn't the best. However, if you use something like strings or B strings, that will let you go ahead and pull that out. You can then obviously pipe that to find string or grep, and you can look for whatever you're interested in, or just manually parse through that. Okay, and in the business version though, of the CID.dat file, it's a little bit different. So obviously this last one here is the personal version, and we were able to easily see those directory names. With the business version though, it's a little less apparent. And so from what I've seen here, if you open up that CID.dat file, the files, it either is a hash or some type of grid there. And so when I thought maybe it was obfuscated, and if I just open up that obfuscation string map text file, and correlate that across reference it, I was able to find some hits, but it was more so on the de-obfuscation side, and I wasn't really able to go ahead and figure out what those file names were. So it may also be an MD5 hash or some type of grid. I haven't really been able to figure out how on the business version to see all the file names. Okay, so with Microsoft OneDrive, the CID.ini file as I mentioned, it's gonna be a couple of different variables that you're gonna see in there, depending if it's personal or business, but essentially what you are gonna be able to see is the CID of the user and the location of the URL of OneDrive for that user. You'll be able to see the last time they synced in Unix epoch time. You'll be able to see the sync activity, bytes transferred, so you can see how active they are using OneDrive. The CID-profileServiceResponse file, that one gives us a plethora of information. However, I have not seen this file get created for business or office 365 accounts. It only seems like it's for personal accounts. If you got the personal account though, as I mentioned, you're gonna see the display name, first name, last name, CID, email address, phone number, title, address, and so much more. However, a lot of those things like job title, when I created my sockpucket account here for OneDrive, it did not ask me for a title or address or phone number. So maybe a user would go into their profile and update that stuff, but by default, that's not required, Phil, to create a OneDrive account or a live account, and so I did not need to do that. Therefore, I didn't fill it out, that's why you're gonna see a lot of null fields there. So when I did redshot and I took a look at, well, what registry keys are being created here by OneDrive? We can see that with the business version, we have quite a few registry keys, with personal it's less, and then I did a difference on those. And so the difference is that, or the commons all the way on the right-hand side, and then the registry keys that the personal account had that the business did not have is gonna be the isUpgradeAvailable and vault shortcut path. Otherwise, the keys that the personal account had were similar to the business account. So the other cool thing you're gonna see, if you look at the registry hive, and you can take a look within HKEY current user software, Syncngins, Providers OneDrive, on a business account, if you look in there, you're gonna, you possibly are going to see some different random characters, it may be a CID or a GWID, but essentially when you look at that, those are items that are shared with the user that you are enumerating. And so what that tells me is that they have received shared files from another user within OneDrive. If you actually do a RegQuery on any one of those, you're gonna go ahead and then get more details about that, such as what the actual share name is. And so we can see there on the mount point, it is where it's located, and it also tells us the name. So it was called something project documents. And then we actually get the URL and the namespace for that as well that we can go ahead and try. Now, one thing about this, whether it's personal or business that I've noticed is that you will have to accept the share, right? So if someone just shares it for you and you see it in OneDrive online, it doesn't mean that you're gonna see that Registry key here created. What happens is you have to click the add share. So if someone shares it with you and you click it to add it to your OneDrive, that action of adding that folder will go ahead and then create that Registry key on all endpoints that are synced. So I created a second SOC Puppet account and created a file or a directory called test and added that to this user's OneDrive account. And once I click add, that's when that was created. And with a personal account, unlike the business account where you get more of that long string of random characters, with the personal account, you don't even need to go any deeper. Just as soon as you go into the OneDrive key, you're gonna see there's the sub key called test and that was added there. So rather than creating that CID or some unique ID for the share, it's gonna have the actual name of the share in there. And then if you actually go into that sub key of test, you're gonna go ahead and see the CID of the user that shared it. So you won't get their email address or username, but you will actually see the CID and maybe you've compromised that other user in the environment and you can then go ahead and just cross-reference that to see who the owner is. So Microsoft also has this feature called Spacesaver. And so what they do with Spacesaver is that they, back, let me start again, with the early days of Cloud File Storage, whether it was Google Drive or Box or Dropbox, getting them all mixed up here, they were, you could selectively sync files and folders, but it's kind of a pain if you had nested folders and you only wanted certain things synced. I remember I had terabytes of stuff up in Box or Dropbox, one of those solutions. And it was just challenging to figure out on all my computers which ones I wanted to sync or didn't sync. And so a lot of these Cloud File Storage solutions have adopted the philosophy of caching files. And so Microsoft, they have this new solution that allows users to view files and their names, but they're not actually stored on the machine. Unless you open them, they're gonna pull them down. So in Dropbox, for example, they have Smart Sync. It's a similar type of feature. If you ever looked at OneDrive, if you ever looked at OneDrive, did you see those different icons on the status that's telling you if it's cloud only, always local or cached locally. So let's now talk about Google Drive. So in Google Drive, I keep calling Google Drive just because I'm old school, but really the personal account or personal version of Google Drive is gonna be called backup and sync. With business, they have migrated that over. So if you have G Suite, what they're gonna use is a tool called Drive File Stream. I tested mostly the personal account just because I didn't have a G Suite account, but they are using SQL-like databases rather than text files and registry keys like OneDrive used. So within Google Drive, if you are using the business version, the Drive File Stream, what happens is it creates a virtual volume in Fat32 and it mounts that. So it's almost like a mounted drive if you were a network share. Synced Google Formatted Files, what's interesting about those is that if you actually open up these files, like a Google Sheets document that was created and on the web version, it's going to download that, but you can see the size there of one kilobyte. It's super small and Windows Explorer. And what's happening is that any Google-native files, whether it's presentation, document, if that is a Google-native file type, what's downloaded is not the actual file. What it actually does is kind of like a shell item, which has the URL, the doc ID and the email address associated with that file. And so a couple of cool things is just looking at that, if you open it up a notepad or a hex editor, you should be able to see the actual file path to get to that Google Drive link or that document. You'll see the ID, which isn't super relevant, but you also can see the email address associated with that, which is kind of cool. Okay, some of the other files and folders and databases and stuff that we'll see, we'll be able to see in the sync underscore config.tb. We'll see the user info, their preferences, initial application, install information. So when they installed Google Drive, in the cloud underscore graph.tb database, we'll see metadata for local cloud and shared files and folders, which is cool. sync underscore log.log is files added, deleted, modified, renamed within Google Drive. The snapshot.tb database has local file metadata within it. The content underscore cache directory has local file caches for G Suite users only. So we can actually see content that possibly had been deleted. And then within the metadata underscore SQLite underscore DB, we'll see offline files, cloud and deleted file metadata. So we look at that sync config database, there's a couple of things just to look at to identify who the user is. We can see their user email address and some of the sync time, the application version, see if there's any vulnerabilities with that. So it'll look something like this if you open it up with DB browser for SQLite. And within the cloud graph database, we'll see things like the Google Drive document IDs, which are unique file and folder object IDs. We'll see file names, the original or human readable file names. We'll see the time when the file was added to Google Drive. Most of the stuff we're gonna take a look at with timestamps, time and date stamps are gonna be in Unix epoch times, just keep that in mind. And the ECL role column, we're gonna see whether or not the user you're looking at is the owner of the file or it's a different user. So whether someone else shared it with that user or not. And probably the most verbose piece and more so than any other solution will look at is the doc type column within this database. And so if you look at the cloud graph entry table within this database, that's gonna go ahead and give you the doc type column. And there you're gonna see different numeric values. And those are gonna tell you whether the object you're looking at is a folder, a traditional file, so let's say PDF or Microsoft Word document. And then the numbers two through 13 are reserved for Google native files. So it'll actually tell you whether or not it was a Google native presentation, which would be a number two. Four would be a Google native spreadsheet, so Google sheets. And then six would tell you if it's a Google Word document, essentially a native Google Word document. And then the removed column, I could not get that to fire off. So when I deleted things locally in the cloud, I wasn't getting any modification of that column. And then Google also gives you an MD5 hash. Most of the solutions will give you a SHA1 hash, but Google gives you the MD5 hash of that file that you're looking at, which could be useful in certain situations. Here's an image of what it would look like if you open it up and DB browser for SQLite, all the columns I was talking about. And then our synclog.log file, it's insight into users activity and their personal accounts. So whether they are creating files, deleting files, modifying files, re-gaming files, changing files and so on, changing ownership. It is a bit messy and convoluted, so I do recommend you either grab it out or you put it in some type of SIM where you can manipulate the data and get what you're looking for. I do recommend in grabbing or parsing for those keywords as action.create, action.delete, to try and find things for you. The synclog.log also give us other things about direction. So it'll tell us whether the file was first added to Google Drive or if it was added locally by the user and then uploaded to Google Drive, whether or not it's shared with other users in the organization. And then the other thing you can grab for or parse for is name equals you and then semi quotes around the file that you're looking for. So if there's a specific file name or you wanted to do a wildcard like pass or password, you could obviously do that format as well and just parse out any words that have those keywords that you're looking for, which is definitely helpful when you're looking for sensitive data on a pen test. Okay, and here's just an example I wanted to show you. If you're taking a look at the synclog.log, I use Sumo Logic just to do a log reduce and so we could see some of those actions. In this case, we can see that there was 22 download actions that were taken. So something was pulled from Google Drive to the local system and you could just kind of get like a count on the different activities there. But again, however you want to do this, to try and figure out what's going on or every use case can be different for what you're looking for if you're using this on a penetration test or a red team engagement. The snapshot.db, we're going to get all kinds of stuff here. There's another database that we just looked at prior that was very similar. The thing that this database adds is that we're going to also be able to see whether or not the item is shared with other users. So that's some additional functionality we get with the snapshots.db database. Here's a screenshot of what that would look like if you're looking at it with DB browser for SQLite. Now, one thing you can do is you can recreate the folder structure that the user would be seeing within Google Drive here. And so looking at some of these, you might see the doc IDs, but not really know is this document you found within this folder or where is it sitting? And so looking at the cloud relations table within, I believe it's within snapshotsdb and cloud underscore graph.db, you'll be able to then see the child and parent doc ID and you can recreate some of these things and figure out where these objects are stored. And so it's not super straightforward and I don't have a expedited process for you here just with my testing, but this is what you would do is if you take the cloud entries and so, or whatever you're looking at there, but you would see that there's a document called finance or a document called the Mike Wiley something and you would then have to go over to the cloud relations table. And in there, we can then map those like I have on the screen and we can see which files are in which folders or are they in the root or where are they sitting within Google Drive. Let's go ahead and take a look at Dropbox real quick. Now, I did not do a lot of testing on Dropbox because one time constraint two, I was having issues with how Dropbox is handling their databases. So kudos to Dropbox, since 2011, they've been using encrypted SQL like databases. So they're using SQLite encryption extension, SEE, since 2011. So all these other solutions we have talked about and are going to talk about is that anyone who has access to the databases or log files can see all of these artifacts, activity and file names and whatnot. Whereas with Dropbox, that is protected. Now, the key is stored in registry and it's encrypted using Windows Data Protection API, D-PAPI. And so there's a couple of options. You can either brute force the password, good luck. Some of you probably have rigs way better than mine that can go ahead and do that, but that didn't seem feasible to me in my time constraints. You could also then extract D-PAPI from memory. There is another talk about that where this worked. I tried to follow some of the stuff from the DC WinDB Toolkit to extract those keys, but I didn't have success with that in a limited time I had for testing. So what you can do is look at some of the Dropbox.cache files. Those contain miscellaneous temporary cache files that possibly were deleted by other users. I was able to get to some of that stuff without obviously having to get through encryption or find the decryption keys. The logging, or sorry, the deletion on files that are local. So if you go ahead and delete something, it's going to send it to the local Recycle Bin and Windows machines, and that does not get purged. So unless obviously the user purges it. Whereas on the cloud, it's going to, if the user delete something, it goes to the cloud, Recycle Bin and Trashcan, and it's going to sit there for 30 to 120 days, depending on their subscription level and how much they're paying. But locally though, it could still be sitting in Recycle Bin. So if you are looking for something, I do encourage you to look in the Recycle Bin. If they haven't cleared that, you may be able to see purged things there. And so those encryption keys, as we were talking about, give the different locations on the screen here before you can find that. Now, Nicholas and Florian did a talk called a Critical Analysis of Dropbox Software Security at HackLU in 2012. I recommend taking a look at that. If you are more interested in this, they were able to get into Dropbox databases. I did try some of the stuff that they talked about and some of the tool kits out there. There are PS1 files, so PowerShell scripts, as well as I believe they were Python scripts. And neither of them really worked for me. So I got different errors. I tried debugging for a while and eventually moved on to the next tool. So it has been done, can be done. If you are really interested, I encourage you to go check that out. Again, a Critical Analysis of Dropbox Software Security at HackLU 2012. I believe there's a YouTube video out there on this. This is allegedly, you can go to the GitHub, play with it yourself, but you should be able to, if you tweak that a little bit. And if you do, please let me know on LinkedIn and Twitter. I'm curious on what you had to do to get it to work. Probably something simple. Some of the files and folders and databases that were created when I installed Dropbox, we can see that there are the Dropbox cache and the Dropbox files that have temporary files that are possibly opened or cache. So you can dig into that without decrypting the databases. Anything else though, that the file cache.dbx, there are some duplicate directories as far as, not directories, but databases, host.db and host.dbx. They look similar, just a slight difference in the extension type. I could not access either one of them. And so any one of those that you see, oh, look, it's actually.db and it's not dbx. I can get in there from my testing, those were still unreadable. The other thing you can find, there's an info.json that's unencrypted and you can find the file store path, host ID, team settings, subscription level and type, how much they're paying. Not terribly useful, but you can get tiny bit of information from that, but Dropbox really, I liked that they didn't encrypt the databases and didn't give you a whole lot of information without having, without decrypting those databases. So kudos to them again. Let's take a look at some of the box files. So obviously you'll find the default file store, but probably one of my favorites is the cache directory. And within the cache directory, you're gonna find full copies of files that were previously opened by the user locally. So if they have box and they go ahead and open a file, whether or not that file still exists within the box file store, you still will be able to, in most cases, even if it's deleted, you'll be able to find a version of that file in the cache directory. And so I have tried in lab environments, went ahead and deleted the file in box and the cache copy is still in the cache directory. Now the file name will not be the existing file name. So obviously you can go into some of the other databases and map that back, but you can easily open the file in the cache directory in a hex editor or text editor and be able to see what type of file it is and open it in its respective application. Within the logs directory, we'll find a bunch of different log files, such as the box-version.log, which is a detailed activity log. We'll find the box UI underscore some random number, underscore the date.log. And that is gonna be generally things associated with the box application. So when the user signs into the local application, they sign out, network activity. It's a very detailed user interface logging. I'll call it that. We also see the box-interstore stream underscore number and then underscore date.log. And that's gonna have file activity, such as files, paths, level of logging, free space on the volume, et cetera. It's got a lot of detailed information about files in, out and activity around them. The data directory is gonna have a path through our databases. We'll see databases such as the syncDB, streamfs.db and metrics.tb. So if we take a look at the box-interstore streams, underscore number, underscore the date, and you'll find quite a few. In my test environment, I had just a handful of files and folders, maybe less than 30 files. And I was already seeing multiple versions of this log file with different dates on them. So it does seem like it rolls over pretty quickly, and there's a lot of activity in these files. We'll see things with key actions, kind of like we saw in prior applications. We'll see add file, add folder, on delete file, on delete folder, on open file, on close file, on read file, on create file, on write file, and on get file info. These are some actions that I've identified just parsing through a couple of these logs that look interesting, and things that may be relevant to you. If we take a look at the box-interstore streams, underscore number, underscore date.log, as you can see there, we'll see things like the cache paths. So if that was modified or changed or anything like that, you could see the cache location. You'll see database paths. You'll see the mount path, et cetera. You'll see a lot of stuff in there. And my favorite is that, as I mentioned, that box cache directory. And so you can see there within the directory, we've got these, what looks like, GWID, possibly a hash file names. It doesn't tell us what the originals were, but if you open them up, what you're gonna see there, and this one was easy, I opened up in a text editor and we could see the magic byte there, and we could tell what type of file it was, but it may be a file type that notepads not going to understand. And so if we do have a hex editor, opening that up and taking a look at the magic bytes, gonna be the preferred option there. And we can actually recreate or view those cache documents, which is great. The box I used, I mentioned log file, there you can see things like driver install, driver events, sign ins, cache events, all kinds of activities around the box application itself. The box-version.log, there we can see that there are some file names, test.txt, when content was created again, and Unix epoch time. And then we've got that database directory with a couple of those databases we've talked about. And the sync.tb database, we're gonna have a ID of objects or files, folders within box, we're gonna have a type, whether it's a file or folder, we don't get that granular level of document type like we saw with Google Drive, but at least we can tell if it's a file or folder. We can then see the parent IDs, we can recreate the folder structure within box. The file name, we get the owner ID of whoever owns that file. So if someone else owns that file, we should see the owner ID of that user. We will see a hash, in this case, unlike other applications we saw in MB5 hash, we'll see a SHA-1 hash within box. We see when the file was created, updated. I will mention with these, I have not tested the created date or updated time to verify when they're triggered, when they're modified and that kind of stuff. So that's a little bit more research or something you may wanna take a look at and not just trust those dates out of the box. No pun intended. Sync.tb within that database, as I mentioned in the last slide, we've got those different fields. Here's an example of what you might see if you open it up in DB browser for SQLite. The stream fsdb, there we're gonna see a touch sequence. I could not find documentation or really reverse engineer what that was doing. We see a cache data ID and that's the file name of the cached version that's sitting in that cached directory. So a few slides ago, we saw that cached directory and it looked like a grid or some hash of the file name. It wasn't the original file name. Here's where we can actually see and map that back to its original file name. So that's the cache data ID is the cached version file name and then obviously the inode ID, we can look at that and then reverse engineer that if you will, looking at the prior databases and find that inode ID and be able to see the original file name. And then also we'll get an age column which gives us the when a file was cached. Zero, you'll see in that column if it is not cached. If it is a one, it is cached. So we'll take a look at that, or I'm sorry, not a one, but we'll see the UNIX epoch time of when that file was cached locally. So in that far right column there, you'll see a few different date timestamps when those files were cached and then all the other ones there that were not cached locally on the system that we were with compromised. Okay, and so with the streamsfs.db database, if we take a look at that, obviously there, you can see in the names column of the syncdb and that's where we can recreate the file name. So again, going back to the streamsfsdb, we can see that there's a grid or hash there of a one, b four, five, et cetera. That's what we would have seen in the cache directory if we want to know the original file name. We go over to the inode ID column, we see that it's 13. We then open up the syncdb database and we can look at the inode ID for 13, which then go into the left-hand side there. We can see in the names column, it was called business plan. So that's how we can recreate those file names if we do find interesting cached files sitting in that cache directory. And here's just another example of a cached item that we can open up in the cache directory and we can see the magic byte of PK. And essentially we can see that that is a docx document so we can open up that in Microsoft Word or change the file extension to docx and open it that way. And here we can see obviously I didn't have Microsoft office installed, but I was able to open it up in WordPad and we can now see that that is in fact the business plan for startup business document that we saw. Okay, and just a couple of things on those columns within the streamfsdb, we can obviously see whether it's a file or folder, the parent, inode ID, the name of the file, we'll see multiple timestamps, the created at timestamp, the modified timestamp, access timestamps, again, you may want to do a little bit of testing on this if that's important to you. I don't know exactly what events will trigger that and I just want to warn you of that. We'll also see the inode ID of the object we're taking a look at and we'll see whether or not the item or the object is marked for offline use, essentially kept offline or cached. And then we'll also see folder fetch timestamp, so it's an again, UNIX epoch timestamp or the last folder sync for that object. Let's go ahead and talk about Citrix share file for a second here. A little intro to it, the application to download, unlike all the other applications we've talked about, it's behind a signup wall, so you cannot just go download it like you would for OneDrive or Dropbox or anything else like that. You actually need to register for a trial of it using what they say a business or enterprise account. However, I was able to use a Gmail account for a trial request, instantly got the download link for that and signed up. And then upon installing share file, it what it looks like is it creates a virtual volume, fat 32, similar to what Google Drive is doing with FileStream, and it will automatically create a mounted S drive for you on that Windows system. For what I see, the databases are SQLite and they are unencrypted, so yet another unencrypted database. The key things that I've noted here from testing is that obviously the S drive or volume is what the default file store. We'll see within user profile, there's app data, local Citrix, and then within Citrix, you'll see a couple other directories and files of interest. Within Citrix files slash DB, there's an ID and this ID seemed to change, it was probably based off of my trial. That seems to be where most of the databases are stored, so possibly the ID directory is created so that if you have different share file accounts, they're stored in different directories. The remote DB, it appeared to have a list of all files that were remote and folders as well. And then we have a local item.db and that lists all the local files and folders. There's also a logs directory and that's where they store all the different log files. And then there's a Citrix file underscore and the date.log and that seemed to have detailed activity about what's going on with share file. And then I also identified that they had part cache directory and that seemed to have all of the cache files that I opened up locally on the window system. So if we see here the DB directory and then some ID or GWID number, that's where we've got all the different databases. You can see there's more than I mentioned on the prior slide and the reason for that is that there are certain databases that were near empty or didn't seem to be having unique information. So I kind of left those out. Within the remote DB, we'll have a couple of different columns. If we open that up in a database viewer for a browser for SQLite, we've got folder IDs, parent folder IDs, file names and global share file IDs. So it's a sign of unique ID. And we can see here the different files that I had within share file. We can obviously the name, there's a bunch of different file names that I had for testing and then the unique ID to the right of that. The remote DB database, it's got a object ID in the database. It has a parent object ID. It has an identifier for the item, whether or not if it was a file or folder. So you can see indications again, similar to the last example we looked at, not as detailed as Google Drive, but at least we can tell if it's a file or folder. We get a created date and UNIX epoch time. We have a file hash and quite a few other columns that didn't seem super relevant for this talk. So here's just a sample. You could see there's a lot of different columns here. Quite a few were gnarled out. And other ones just didn't seem relevant for offensive security purposes. The local item database, we can see things like the key. There are certain columns here. I didn't have great explanations for, so I left those blank. But again, we've got the change date, last access date, last write date, an ID number, which not sure how that differs from the share file unique ID we saw prior. There's the content ID. Again, not sure how that differs from the key or the ID. And then the creation date, time and object was created in UNIX epoch. We did get another interesting one, is there's a URL column. And that gives us a cloud URL. So it's the instance ID. I don't know if this changes for paid accounts versus trials, but I had some kind of trial instance ID.sf-api.com slash sf slash v3 slash items. And then the item ID, which matched up to the other ID column that we see here on the screen. And so I thought that was pretty interesting. When I went ahead and tried to access that with a browser, Firefox or Chrome, it would not give me access to those files. Now, I would like to do some further testing on that and figure out if we can use other tools, aside from a browser, to go ahead and access those files without authentication. That seems like it may be a security issue for ShareFile, but I have not validated that yet. We also see a file hash and there's quite a few other columns that we see. Within the directory entry.db database, we just get very limited information, a parent ID of an object, file name, ID of an object. If we go ahead and take a look at the Citrix files, underscore date, and then it actually has the date of the file.log, we'll see other actions that we may want to parse out, using strings or grep or something like that. Upload file, and these are all in brackets. You want to search for those file system notifier, local, win, fsp, delete item, download, upload, recall back. Those are all interesting things that I found within those log files. If we go ahead and take a look at that part cache file, it's exactly the same as we saw in the last example for box, where in this case though, it seemed to rename it rather than some type of grid. The directory, the parent directory would be some type of grid that or hash or something that identified that file, but then within that, it was a single cached file. It was generally called zero dot part. However, if you open that up, and again with a hex editor, you'd see the magic bite, you see that it's a word doc, and we could just change the file extension to dot dot x, and we could go ahead and open up that file, whether or not it was deleted within share file, we now have a cached version of that. So in closing, one other way that you may be able to take a look at things, if a user is not actually, or they have not installed the application, but they are using cloud file storage solutions, you want to numerator a little bit about what they're doing. I identified some things within Google Drive where if they were using or viewing or editing Google spreadsheets, you would see within their browser history, docs.google.com slash spreadsheets. If they were editing or viewing a presentation, you could see docs.google.com slash presentation. Not a ton of great information from that other than that they are using Google Docs in the environment, and you may have to then attempt to gather documents else or a different method. But obviously if they are using a browser, you have access to their browser, Google never signs you out, so you should be able to obviously just open a browser and access the documents there, but this is a tell tale sign that they are using probably G Suite or Google Docs for the workplace. We can also see other tools, for example, Box, whether they were in the root directory, it's gonna have app.box.com slash folder slash zero, and then we will see other indications of different folders, but at least you can see that they have signed in and that they were looking at the root of box.com if you see that folder slash zero. With OneDrive, you're gonna see OneDrive.live.com slash question mark ID equal root, and you'll see that they have a personal account there and they are looking in the root directory, you'll also see the CID of their personal OneDrive account. For business, it's a little bit different. They're probably gonna be using SharePoint. If you're using Dropbox, we can see that it's just Dropbox.com slash home, which wasn't a great indication of what they were doing within Dropbox. With viewing an actual document though, showing that they have signed in and they're actually viewing content, you'll see Dropbox.com slash SCL, and that will indicate that they have actually viewed documents within Dropbox. Also, if they are viewing the contents of a folder, you're gonna go ahead and actually see the folder name as well, so it's gonna be Dropbox.com slash home slash the folder name, you'll get some indication of the different folders, whether it's accounting, HR, et cetera. Now, one thing I did create for you if you wanna go ahead and shoot me a message on LinkedIn or Twitter, happy to share this with you. Once I created my lab environment, and I wanted to go ahead and collect those, the metadata and the artifacts that were left behind, what I did is I created a CAPE target, and so I utilized CAPE, which generally I would use more in the instant response or digital forensic case to do a triage image of a system. The reason that I like using this tool is that you can see here using this custom target that I created, it took 12 seconds, just under 12 seconds to go ahead and collect all that data. So if you wanna play around with this or try and test this out, see what kind of CAF files are left behind or that you can enumerate, it's very easy to do. You can obviously pull these yourself, but I found it useful to use a CAPE target so that I could just collect all of the different data from the different cloud providers very quickly. And so I've got to snip it there. I can give you the GitHub link if you go ahead and send me a message on LinkedIn or Twitter as I mentioned. And that wraps up.
 Cloud File Storage Gems.  I'm Michael Wiley,  Director of Cybersecurity Services  at Richie Mae Technology Solutions.  Prior to joining the firm,  I owned a boutique cybersecurity firm  in Los Angeles, California,  where I performed penetration tests,  red team engagements, fishing campaigns,  social engineering, and so on.  These days to do a bit more around compliance,  digital forensics, instant response,  and security architecture.  I've got plenty of certifications  I've collected over the past few years,  and I enjoy what I do tremendously.  I encourage you to connect on LinkedIn  and follow me on Twitter.  Those are probably the best two ways  to get ahold of me after this talk.  About Richie Mae.  Well, the firm was founded 30,  going on 35 years ago as a tax and audit firm.  A while ago, transitioned into business advisory,  and during that process,  the firm realized that they wanted to  advise their clients on technology and cybersecurity.  They brought in my boss, who's a former CISO.  They acquired my firm and a couple of others  to build the team that I work with today.  I focus on the media entertainment industry,  while the firm's other niche is the financial sector.  So I get to work with a lot of studios and vendors  that make the movies you love happen.  Some of the learning objectives  we're gonna go over in this talk.  We're gonna learn what file artifacts are available  in cloud file storage applications.  We'll see what kind of cloud file storage user activities  we can enumerate during a penetration test.  We'll be introduced to application logs  and what's available there,  and examine the difference between  cloud file storage providers.  So first, I wanted to give some credit where credit is due.  Some of this I have come up with from my own testing,  from forensic cases that I've looked at,  as well as a lot of reading from other people's work.  So just name a few of those who have created content  and things that I have read, come across,  looked at their research labs, et cetera.  These people are due credit.  So why are we talking about cloud file storage solutions?  Well, back in the day,  obviously we had file servers on-premise,  and that's the, most of the time,  the crown jewels, what we're looking at during that test.  It could be obviously a database or something else,  but a lot of times you're gonna find those GC gems  on a file server.  These days, we seem to be doing it rich in May.  A lot of migrations helping customers move away  from the traditional model of non-premise file server  and trying to utilize some of these cloud file storage  solutions like Box, Google Drive, OneDrive, Dropbox,  Sharefile, et cetera.  And so some of the perceived benefits  that organizations get to this  and why they're making that transition is that,  one, there's protection against disasters,  for the most part, right?  So whether it's the pandemic, you can go home  and obviously access Google Drive,  whereas if you had a file server on-premise,  you'd have to be VPN access  or some other way to get to those files.  There's a decrease in maintenance.  So IT departments don't have to sit there  and patch file servers.  They don't have to work on ACLs.  They don't have to troubleshoot DFS issues,  sync problems, all those kind of things.  There's also the perceived high availability aspect of it.  Sure, cloud can go down from time to time,  but for the most part, these cloud file storage solutions  are having uptime higher than file servers  that are sitting on-premise.  They're also scalable.  So Google will happily sell you an extra terabyte  or two terabytes of space  with just an increase in your price  of your monthly subscription.  Whereas if you have a traditional file server on-premise  and you're running out of space,  you may have to add hard drives to a RAID cluster  or add systems to a cluster  or whatever mechanism you're using to get more space.  It's also, there's some ease of management, right?  You don't have to get into a Windows operating system  and adjust file permissions or folder permissions  or share permissions.  You can just basically make a couple of changes  from a web interface.  There are a couple of uses that we're gonna take a look at.  And so if you do end up compromising a system  and you suspect or see  that there was a cloud file storage solution there,  you may run into one or two scenarios.  One, it may be business authorized.  So there may be a cloud file storage solution  that the business has paid for, implemented and deployed.  And there may be some differences  than if you find the application installed,  but it's a personal account that they have logged in with.  So in many cases, I've gone in from both perspectives,  offensive or defensive,  and we have seen applications installed  that were not sanctioned by the organization,  but it was either a employee who thought they were doing good  or they wanted to just access their files  and they downloaded Dropbox or Box  or some application and started syncing files.  So what are those different solutions out there?  Well, we're gonna talk about Microsoft OneDrive,  Google Drive, Dropbox, Box and Citrix ShareFile.  And the data here was pulled up from,  I believe it was SolarWinds did a study on this  and they outlined small, mid-size or large businesses  and which solution they're using.  So you can obviously see Microsoft OneDrive,  it's baked into Windows 8 and above,  so a lot of people are using it,  but when you start getting to some of the other solutions  like Box, you can obviously see they're focusing  on larger businesses in that market share.  So there's, as I mentioned,  there's two different scenarios that we might run across.  One is where the remote system that we've compromised,  it's they're running a cloud file storage solution  that is sanctioned by the corporate environment.  And in that case, there may be CASB or off-site logs  or other security controls where they're monitoring  or controlling what's going on.  But we may run across the other scenario  on the right-hand side there,  where there's the sanctioned cloud applications  that may have CASB that is not in line  or other security controls,  but they're also using a personal version of Google Drive  or OneDrive or something like that.  And that may bypass some of those shadow IT  or security controls that the defenders put in place.  So what are some of these gems that we may uncover  as we see that there is a cloud file storage application  on a system we've compromised  and what can we get from that?  Well, if you think of cloud file storage solutions  as replacements of file servers,  we may see customer data, financials, employee data, HR.  You wouldn't believe some of the things  that I have seen people store in cloud file storage solutions  and with laxed security around them.  Some of the things that these cloud file storage applications  may leave behind that of interest to us, cached files.  So whether those files are stored on the cloud  or local or local, but then they were deleted, we see,  we may be able to recover these cached files  and actually see or recreate some of those files.  We may see the local files,  we'll get a database with all the files  that are stored locally,  but more importantly in the cloud as well.  So we can see what is out there  that maybe the user doesn't have stored locally.  We'll see file usage and their behavior around those files,  what files they're accessing most frequently.  We'll be able to find traces  of possibly deleted files as well.  So as I mentioned, there is either a business  or enterprise account and that may be company issued.  There may be additional logging and security controls  that the security team or RT team has, such as CASB.  There's also more logging generally in the cloud  if it is a business or enterprise account.  Whereas if you stumble upon a free account  that someone has on a system you've compromised,  it may not be company issued,  so there may be no knowledge of it.  There may be no access to the actual account itself.  That may be not synced with Active Directory  or LDAP or single sign-on.  So we may not be able to gain access to that right away.  There's no central visibility by the defenders though.  So they're not gonna see the things  we're poking around or accessing.  And then we're also gonna be able  to find some local logs there.  And so the difference between those business enterprise  accounts and the personal free accounts is that  there's a lot more storage with the business accounts  that are built in obviously depends on what you're paying for.  But you might have G Suite,  the equivalent to a personal account would be Google Drive.  It's not exactly called that,  we'll get into that in a second,  but 15 gigs of free space there.  So even if it's not a sanctioned account  and someone just installs the Google Drive app,  you can have up to 15 gigs of gems  as you can find there.  With Officer 65, it comes with OneDrive subscription there.  OneDrive basics, the free alternative with only five gigs,  Box, Business, or Enterprise.  You can have different levels of storage,  but you can also get two gigs of free storage  with a basic account.  Dropbox Pro, the equivalent for a free account  is Box Starter.  This may have changed since I built this slide a while back.  It used to be able to get about 100 gigs of space.  I think they have limited that.  So let's talk about Microsoft of OneDrive first.  Let's get into it.  That's the one that's baked into Windows 8 and above.  It must be enabled.  So it's installed,  but you need to enable it via authentication.  So once you sign in, it does a couple of things.  Add some registry keys as well as it creates  the OneDrive directory sitting in app data, local, Microsoft.  So that folder will not be there.  That directory will not be there  until you authenticate with the OneDrive application.  Now, if you have a personal account,  you're gonna see within app data,  local, Microsoft OneDrive logs,  you're gonna see a personal folder directory.  If they have a business version of OneDrive,  you're gonna see business one.  Now, I believe the reason they do business one  is because that you can install  or sign into more than one account.  And so you might see business one, business two, business three,  but the primary account should be business one.  With Office 365, the defenders do have a unified logging.  And it is by default enabled  from my recollection up to 90 days.  Now, from the instance I've been working more recently,  and what we see with some of the like the Mandiant dwell times  and Verizon DBI reports and whatnot,  is that our dwell time is getting better,  but it's still pretty long.  And so that 90 days of retention may not be enough  for the defenders to see what's going on,  especially in the red team engagement.  So, but even with a personal account though,  there's no central logging from what I can see  on the web interface of OneDrive.  So all those logs are stored locally.  And obviously maybe you can subpoena Microsoft  or get whatever logs they have,  but at least from the availability  for IT and security professionals  who are trying to investigate what might have happened  or who access this, it's a bit limited.  Right, and so on the left hand side there,  we can see in app data, local Microsoft OneDrive logs.  We've got a couple of different logs  that are stored locally on the endpoint.  And on the right hand side,  we see the business unified logs.  So a couple of interesting directories and folders  that I've outlined here for you,  is that some of the things we can see  if we've gained access to a system  that is syncing with OneDrive is that the user profile  slash OneDrive is the default data store  of where things are gonna go.  If it is a Office 365 business account,  it'll be OneDrive dash and the company name.  So we'll be able to see what company they work for as well  and make sure it's obviously in scope.  The, we'll then see the root directory  within the logs directory, which is kind of strange.  We'll also be able to see some metadata  for local and cloud files.  So even if the file is not synced locally,  we may be able to see it in the sync diagnostics log.  There is a big maybe there I'll talk about in a second.  And then we're gonna have a, a dat and in i file.  And those two files, it's going to start the,  the actual file name is gonna be the customer ID  or the CID of the user.  So you'll see with the CID.dat,  you'll see a list of local and cloud file names.  So even things that are not synced locally,  you'll be able to see those.  And the CID.ini file will be able to see the file store  locations and sync time usage details  and some other metadata there.  We're gonna see another file that starts  with the CID of the user, followed by a dash  and profiles service response.txt.  That will give us the name, email, CID, email,  phone and title, et cetera of the user.  That only is the case though for personal accounts.  When I tried it with Office 365 or paid versions,  I did not get this file.  I find that interesting because most people  aren't gonna sign in or add their title  and phone number and address and stuff like that.  I'll show you a more detailed version in a second here.  And most of the time you're gonna see that as null,  but at least you can see the email address  that they have associated with OneDrive.  And then you're gonna also find  a obfuscation string map.txt file.  And that's gonna be important to map back  to obfuscated file names.  And I'll show you how that works in a second too.  So within the syncdiagnostics.log file,  I have observed two different types of files, right?  And so you may get one of two versions.  And I think I've narrowed it down,  but I haven't had enough test cases to verify this.  I'm gonna call one the summary syncdiagnostics file,  and the other one I'm gonna call  the details syncdiagnostics file.  And now what I've noticed is that  if I install Office 365 OneDrive  and I look at the syncdiagnostics file,  I keep getting the summary version.  And, but if I try a personal version  and I've tried multiple labs and syncing it,  what I've generally seen is that  the first machine you activate OneDrive on  will have the detailed syncdiagnostics.log file.  And then every subsequent system you sync with  will have the summary version.  So that's my theory at this point.  Again, I need more testing for that.  And I'll show you what those look like.  So on the left-hand side here,  we've got the detailed syncdiagnostics.log.  And you could see that there's,  in the bottom part of that, there's files and folders  that are presumably added or synced.  And you could see some type of mount point  with possibly a grid.  And then there is a backslash.  And then a three-word string.  So far jump, sue, sue back, egg, and so on.  So those are obfuscated file names.  And I'll show you how to decode those in a second.  On the right-hand side,  you have the summary version of the syncdiagnostics file.  It's not as verbose.  You have statistical data, you know, sync progress.  You've got last sync time,  bytes downloaded, bytes uploaded, that kind of stuff.  And so here's again, a little bit more  of the summary version,  where you could see the number of changed folders,  deleted folders.  It's really high-level information there.  Now, if you happen to get that detailed version  of the syncdiagnostics.log,  what you can go ahead and do is,  obviously we don't know what C bat egg is,  but you can go ahead and open up  that obfuscation string map.  And again, all of these files that I'm talking about,  with the exception of Dropbox,  they are all clear text.  So these files, it's not something special  I've had to open up.  The obfuscation string map is just sitting  in a directory that anyone can access.  And when we look at the syncdiagnostics,  we're gonna have to take that three-word string there,  like C bat egg,  and we're gonna have to go map that  to our obfuscation string map text file.  And so there we can see that C bat egg  essentially equals the desktop.  So it looks like a folder was added to sync,  and that folder was desktop, right?  So it's a little bit of work,  but you can go ahead and map those back and forth there.  Just a little bit more on that obfuscation string map  text file.  I think that last slide showed it in great detail.  Okay, and then so the CID of the user.dat,  if we open that up,  that's gonna show us the list of file names  both locally and in the cloud.  So even if it's not synced to the local file system,  we could see what that user has access to in the cloud.  And it is a little bit challenging to read this dat file.  It's not formatted in the greatest way.  So you can open it up in a hex editor,  and you can even see, you know,  searching for strings isn't the best.  However, if you use something like strings or B strings,  that will let you go ahead and pull that out.  You can then obviously pipe that to find string or grep,  and you can look for whatever you're interested in,  or just manually parse through that.  Okay, and in the business version though,  of the CID.dat file, it's a little bit different.  So obviously this last one here is the personal version,  and we were able to easily see those directory names.  With the business version though,  it's a little less apparent.  And so from what I've seen here,  if you open up that CID.dat file,  the files, it either is a hash or some type of grid there.  And so when I thought maybe it was obfuscated,  and if I just open up that obfuscation string map text file,  and correlate that across reference it,  I was able to find some hits,  but it was more so on the de-obfuscation side,  and I wasn't really able to go ahead  and figure out what those file names were.  So it may also be an MD5 hash or some type of grid.  I haven't really been able to figure out  how on the business version to see all the file names.  Okay, so with Microsoft OneDrive,  the CID.ini file as I mentioned,  it's gonna be a couple of different variables  that you're gonna see in there,  depending if it's personal or business,  but essentially what you are gonna be able to see  is the CID of the user and the location of the URL  of OneDrive for that user.  You'll be able to see the last time they synced  in Unix epoch time.  You'll be able to see the sync activity,  bytes transferred, so you can see how active  they are using OneDrive.  The CID-profileServiceResponse file,  that one gives us a plethora of information.  However, I have not seen this file get created  for business or office 365 accounts.  It only seems like it's for personal accounts.  If you got the personal account though,  as I mentioned, you're gonna see the display name,  first name, last name, CID, email address,  phone number, title, address, and so much more.  However, a lot of those things like job title,  when I created my sockpucket account here for OneDrive,  it did not ask me for a title or address or phone number.  So maybe a user would go into their profile  and update that stuff, but by default,  that's not required, Phil, to create a OneDrive account  or a live account, and so I did not need to do that.  Therefore, I didn't fill it out,  that's why you're gonna see a lot of null fields there.  So when I did redshot and I took a look at,  well, what registry keys are being created here by OneDrive?  We can see that with the business version,  we have quite a few registry keys,  with personal it's less,  and then I did a difference on those.  And so the difference is that,  or the commons all the way on the right-hand side,  and then the registry keys that the personal account had  that the business did not have  is gonna be the isUpgradeAvailable  and vault shortcut path.  Otherwise, the keys that the personal account had  were similar to the business account.  So the other cool thing you're gonna see,  if you look at the registry hive,  and you can take a look within  HKEY current user software,  Syncngins, Providers OneDrive,  on a business account, if you look in there,  you're gonna, you possibly are going to see  some different random characters,  it may be a CID or a GWID,  but essentially when you look at that,  those are items that are shared  with the user that you are enumerating.  And so what that tells me is that  they have received shared files  from another user within OneDrive.  If you actually do a RegQuery on any one of those,  you're gonna go ahead and then get more details about that,  such as what the actual share name is.  And so we can see there on the mount point,  it is where it's located,  and it also tells us the name.  So it was called something project documents.  And then we actually get the URL and the namespace  for that as well that we can go ahead and try.  Now, one thing about this,  whether it's personal or business that I've noticed is that  you will have to accept the share, right?  So if someone just shares it for you  and you see it in OneDrive online,  it doesn't mean that you're gonna see  that Registry key here created.  What happens is you have to click the add share.  So if someone shares it with you  and you click it to add it to your OneDrive,  that action of adding that folder will go ahead  and then create that Registry key  on all endpoints that are synced.  So I created a second SOC Puppet account  and created a file or a directory called test  and added that to this user's OneDrive account.  And once I click add, that's when that was created.  And with a personal account,  unlike the business account where you get more of that  long string of random characters,  with the personal account,  you don't even need to go any deeper.  Just as soon as you go into the OneDrive key,  you're gonna see there's the sub key called test  and that was added there.  So rather than creating that CID  or some unique ID for the share,  it's gonna have the actual name of the share in there.  And then if you actually go into that sub key of test,  you're gonna go ahead and see the CID  of the user that shared it.  So you won't get their email address or username,  but you will actually see the CID  and maybe you've compromised that other user  in the environment and you can then go ahead  and just cross-reference that to see who the owner is.  So Microsoft also has this feature called Spacesaver.  And so what they do with Spacesaver is that they,  back, let me start again,  with the early days of Cloud File Storage,  whether it was Google Drive or Box or Dropbox,  getting them all mixed up here,  they were, you could selectively sync files and folders,  but it's kind of a pain if you had nested folders  and you only wanted certain things synced.  I remember I had terabytes of stuff up in Box  or Dropbox, one of those solutions.  And it was just challenging to figure out on all my computers  which ones I wanted to sync or didn't sync.  And so a lot of these Cloud File Storage solutions  have adopted the philosophy of caching files.  And so Microsoft, they have this new solution  that allows users to view files and their names,  but they're not actually stored on the machine.  Unless you open them, they're gonna pull them down.  So in Dropbox, for example, they have Smart Sync.  It's a similar type of feature.  If you ever looked at OneDrive,  if you ever looked at OneDrive,  did you see those different icons on the status  that's telling you if it's cloud only,  always local or cached locally.  So let's now talk about Google Drive.  So in Google Drive, I keep calling Google Drive  just because I'm old school,  but really the personal account  or personal version of Google Drive  is gonna be called backup and sync.  With business, they have migrated that over.  So if you have G Suite,  what they're gonna use is a tool called Drive File Stream.  I tested mostly the personal account  just because I didn't have a G Suite account,  but they are using SQL-like databases  rather than text files and registry keys  like OneDrive used.  So within Google Drive,  if you are using the business version,  the Drive File Stream,  what happens is it creates a virtual volume in Fat32  and it mounts that.  So it's almost like a mounted drive  if you were a network share.  Synced Google Formatted Files,  what's interesting about those  is that if you actually open up these files,  like a Google Sheets document that was created  and on the web version,  it's going to download that,  but you can see the size there of one kilobyte.  It's super small and Windows Explorer.  And what's happening is that any Google-native files,  whether it's presentation, document,  if that is a Google-native file type,  what's downloaded is not the actual file.  What it actually does is kind of like a shell item,  which has the URL, the doc ID and the email address  associated with that file.  And so a couple of cool things is just looking at that,  if you open it up a notepad or a hex editor,  you should be able to see the actual file path  to get to that Google Drive link or that document.  You'll see the ID, which isn't super relevant,  but you also can see the email address  associated with that, which is kind of cool.  Okay, some of the other files and folders  and databases and stuff that we'll see,  we'll be able to see in the sync underscore config.tb.  We'll see the user info, their preferences,  initial application, install information.  So when they installed Google Drive,  in the cloud underscore graph.tb database,  we'll see metadata for local cloud  and shared files and folders, which is cool.  sync underscore log.log is files added, deleted, modified,  renamed within Google Drive.  The snapshot.tb database has local file metadata within it.  The content underscore cache directory  has local file caches for G Suite users only.  So we can actually see content  that possibly had been deleted.  And then within the metadata underscore SQLite underscore DB,  we'll see offline files, cloud and deleted file metadata.  So we look at that sync config database,  there's a couple of things just to look at  to identify who the user is.  We can see their user email address  and some of the sync time, the application version,  see if there's any vulnerabilities with that.  So it'll look something like this  if you open it up with DB browser for SQLite.  And within the cloud graph database,  we'll see things like the Google Drive document IDs,  which are unique file and folder object IDs.  We'll see file names, the original  or human readable file names.  We'll see the time when the file was added to Google Drive.  Most of the stuff we're gonna take a look at  with timestamps, time and date stamps  are gonna be in Unix epoch times,  just keep that in mind.  And the ECL role column,  we're gonna see whether or not the user you're looking at  is the owner of the file or it's a different user.  So whether someone else shared it with that user or not.  And probably the most verbose piece  and more so than any other solution  will look at is the doc type column within this database.  And so if you look at the cloud graph entry table  within this database,  that's gonna go ahead and give you the doc type column.  And there you're gonna see different numeric values.  And those are gonna tell you  whether the object you're looking at is a folder,  a traditional file, so let's say PDF  or Microsoft Word document.  And then the numbers two through 13  are reserved for Google native files.  So it'll actually tell you whether or not  it was a Google native presentation,  which would be a number two.  Four would be a Google native spreadsheet,  so Google sheets.  And then six would tell you if it's a Google Word document,  essentially a native Google Word document.  And then the removed column,  I could not get that to fire off.  So when I deleted things locally in the cloud,  I wasn't getting any modification of that column.  And then Google also gives you an MD5 hash.  Most of the solutions will give you a SHA1 hash,  but Google gives you the MD5 hash of that file  that you're looking at,  which could be useful in certain situations.  Here's an image of what it would look like  if you open it up and DB browser for SQLite,  all the columns I was talking about.  And then our synclog.log file,  it's insight into users activity and their personal accounts.  So whether they are creating files, deleting files,  modifying files, re-gaming files, changing files  and so on, changing ownership.  It is a bit messy and convoluted,  so I do recommend you either grab it out  or you put it in some type of SIM  where you can manipulate the data  and get what you're looking for.  I do recommend in grabbing or parsing for those keywords  as action.create, action.delete,  to try and find things for you.  The synclog.log also give us other things about direction.  So it'll tell us whether the file was first added  to Google Drive or if it was added locally by the user  and then uploaded to Google Drive,  whether or not it's shared with other users  in the organization.  And then the other thing you can grab for or parse for  is name equals you and then semi quotes  around the file that you're looking for.  So if there's a specific file name  or you wanted to do a wildcard like pass or password,  you could obviously do that format as well  and just parse out any words that have those keywords  that you're looking for,  which is definitely helpful  when you're looking for sensitive data on a pen test.  Okay, and here's just an example I wanted to show you.  If you're taking a look at the synclog.log,  I use Sumo Logic just to do a log reduce  and so we could see some of those actions.  In this case, we can see that there was 22 download actions  that were taken.  So something was pulled from Google Drive  to the local system and you could just kind of get  like a count on the different activities there.  But again, however you want to do this,  to try and figure out what's going on  or every use case can be different for what you're looking for  if you're using this on a penetration test  or a red team engagement.  The snapshot.db, we're going to get all kinds of stuff here.  There's another database that we just looked at prior  that was very similar.  The thing that this database adds is that we're going to also  be able to see whether or not the item is shared  with other users.  So that's some additional functionality we get  with the snapshots.db database.  Here's a screenshot of what that would look like  if you're looking at it with DB browser for SQLite.  Now, one thing you can do is you can recreate  the folder structure that the user would be seeing  within Google Drive here.  And so looking at some of these,  you might see the doc IDs, but not really know  is this document you found within this folder  or where is it sitting?  And so looking at the cloud relations table within,  I believe it's within snapshotsdb  and cloud underscore graph.db,  you'll be able to then see the child and parent doc ID  and you can recreate some of these things  and figure out where these objects are stored.  And so it's not super straightforward  and I don't have a expedited process for you here  just with my testing, but this is what you would do  is if you take the cloud entries and so,  or whatever you're looking at there,  but you would see that there's a document called finance  or a document called the Mike Wiley something  and you would then have to go over  to the cloud relations table.  And in there, we can then map those  like I have on the screen and we can see which files  are in which folders or are they in the root  or where are they sitting within Google Drive.  Let's go ahead and take a look at Dropbox real quick.  Now, I did not do a lot of testing on Dropbox  because one time constraint two,  I was having issues with how Dropbox  is handling their databases.  So kudos to Dropbox, since 2011,  they've been using encrypted SQL like databases.  So they're using SQLite encryption extension, SEE,  since 2011.  So all these other solutions we have talked about  and are going to talk about is that anyone who has access  to the databases or log files can see all of these artifacts,  activity and file names and whatnot.  Whereas with Dropbox, that is protected.  Now, the key is stored in registry  and it's encrypted using Windows Data Protection API, D-PAPI.  And so there's a couple of options.  You can either brute force the password, good luck.  Some of you probably have rigs way better than mine  that can go ahead and do that,  but that didn't seem feasible to me in my time constraints.  You could also then extract D-PAPI from memory.  There is another talk about that where this worked.  I tried to follow some of the stuff from the DC WinDB Toolkit  to extract those keys, but I didn't have success with that  in a limited time I had for testing.  So what you can do is look at some of the Dropbox.cache files.  Those contain miscellaneous temporary cache files  that possibly were deleted by other users.  I was able to get to some of that stuff without obviously  having to get through encryption  or find the decryption keys.  The logging, or sorry, the deletion on files that are local.  So if you go ahead and delete something,  it's going to send it to the local Recycle Bin  and Windows machines, and that does not get purged.  So unless obviously the user purges it.  Whereas on the cloud, it's going to,  if the user delete something, it goes to the cloud,  Recycle Bin and Trashcan, and it's going to sit there  for 30 to 120 days, depending on their subscription level  and how much they're paying.  But locally though, it could still be sitting in Recycle Bin.  So if you are looking for something,  I do encourage you to look in the Recycle Bin.  If they haven't cleared that, you may be able to see purged  things there.  And so those encryption keys, as we were talking about,  give the different locations on the screen here  before you can find that.  Now, Nicholas and Florian did a talk  called a Critical Analysis of Dropbox Software Security  at HackLU in 2012.  I recommend taking a look at that.  If you are more interested in this,  they were able to get into Dropbox databases.  I did try some of the stuff that they talked about  and some of the tool kits out there.  There are PS1 files, so PowerShell scripts,  as well as I believe they were Python scripts.  And neither of them really worked for me.  So I got different errors.  I tried debugging for a while and eventually moved on  to the next tool.  So it has been done, can be done.  If you are really interested, I encourage  you to go check that out.  Again, a Critical Analysis of Dropbox Software Security  at HackLU 2012.  I believe there's a YouTube video out there on this.  This is allegedly, you can go to the GitHub,  play with it yourself, but you should be able to,  if you tweak that a little bit.  And if you do, please let me know on LinkedIn and Twitter.  I'm curious on what you had to do to get it to work.  Probably something simple.  Some of the files and folders and databases  that were created when I installed Dropbox,  we can see that there are the Dropbox cache  and the Dropbox files that have temporary files  that are possibly opened or cache.  So you can dig into that without decrypting the databases.  Anything else though, that the file cache.dbx,  there are some duplicate directories as far as,  not directories, but databases, host.db and host.dbx.  They look similar, just a slight difference  in the extension type.  I could not access either one of them.  And so any one of those that you see,  oh, look, it's actually.db and it's not dbx.  I can get in there from my testing,  those were still unreadable.  The other thing you can find,  there's an info.json that's unencrypted  and you can find the file store path, host ID, team settings,  subscription level and type, how much they're paying.  Not terribly useful, but you can get tiny bit of information  from that, but Dropbox really,  I liked that they didn't encrypt the databases  and didn't give you a whole lot of information  without having, without decrypting those databases.  So kudos to them again.  Let's take a look at some of the box files.  So obviously you'll find the default file store,  but probably one of my favorites is the cache directory.  And within the cache directory,  you're gonna find full copies of files  that were previously opened by the user locally.  So if they have box and they go ahead and open a file,  whether or not that file still exists  within the box file store,  you still will be able to, in most cases,  even if it's deleted, you'll be able to find  a version of that file in the cache directory.  And so I have tried in lab environments,  went ahead and deleted the file in box  and the cache copy is still in the cache directory.  Now the file name will not be the existing file name.  So obviously you can go into some of the other databases  and map that back,  but you can easily open the file in the cache directory  in a hex editor or text editor  and be able to see what type of file it is  and open it in its respective application.  Within the logs directory,  we'll find a bunch of different log files,  such as the box-version.log,  which is a detailed activity log.  We'll find the box UI underscore some random number,  underscore the date.log.  And that is gonna be generally things  associated with the box application.  So when the user signs into the local application,  they sign out, network activity.  It's a very detailed user interface logging.  I'll call it that.  We also see the box-interstore stream underscore number  and then underscore date.log.  And that's gonna have file activity,  such as files, paths, level of logging,  free space on the volume, et cetera.  It's got a lot of detailed information  about files in, out and activity around them.  The data directory is gonna have a path through our databases.  We'll see databases such as the syncDB,  streamfs.db and metrics.tb.  So if we take a look at the box-interstore streams,  underscore number, underscore the date,  and you'll find quite a few.  In my test environment,  I had just a handful of files and folders,  maybe less than 30 files.  And I was already seeing multiple versions of this log file  with different dates on them.  So it does seem like it rolls over pretty quickly,  and there's a lot of activity in these files.  We'll see things with key actions,  kind of like we saw in prior applications.  We'll see add file, add folder, on delete file,  on delete folder, on open file, on close file,  on read file, on create file, on write file,  and on get file info.  These are some actions that I've identified  just parsing through a couple of these logs  that look interesting,  and things that may be relevant to you.  If we take a look at the box-interstore streams,  underscore number, underscore date.log,  as you can see there, we'll see things like the cache paths.  So if that was modified or changed or anything like that,  you could see the cache location.  You'll see database paths.  You'll see the mount path, et cetera.  You'll see a lot of stuff in there.  And my favorite is that, as I mentioned,  that box cache directory.  And so you can see there within the directory,  we've got these, what looks like,  GWID, possibly a hash file names.  It doesn't tell us what the originals were,  but if you open them up, what you're gonna see there,  and this one was easy, I opened up in a text editor  and we could see the magic byte there,  and we could tell what type of file it was,  but it may be a file type that notepads  not going to understand.  And so if we do have a hex editor,  opening that up and taking a look at the magic bytes,  gonna be the preferred option there.  And we can actually recreate or view  those cache documents, which is great.  The box I used, I mentioned log file,  there you can see things like driver install,  driver events, sign ins, cache events,  all kinds of activities around the box application itself.  The box-version.log, there we can see  that there are some file names, test.txt,  when content was created again, and Unix epoch time.  And then we've got that database directory  with a couple of those databases we've talked about.  And the sync.tb database,  we're gonna have a ID of objects or files,  folders within box, we're gonna have a type,  whether it's a file or folder,  we don't get that granular level of document type  like we saw with Google Drive,  but at least we can tell if it's a file or folder.  We can then see the parent IDs,  we can recreate the folder structure within box.  The file name, we get the owner ID  of whoever owns that file.  So if someone else owns that file,  we should see the owner ID of that user.  We will see a hash, in this case,  unlike other applications we saw in MB5 hash,  we'll see a SHA-1 hash within box.  We see when the file was created, updated.  I will mention with these,  I have not tested the created date or updated time  to verify when they're triggered,  when they're modified and that kind of stuff.  So that's a little bit more research or something  you may wanna take a look at  and not just trust those dates out of the box.  No pun intended.  Sync.tb within that database,  as I mentioned in the last slide,  we've got those different fields.  Here's an example of what you might see  if you open it up in DB browser for SQLite.  The stream fsdb, there we're gonna see a touch sequence.  I could not find documentation  or really reverse engineer what that was doing.  We see a cache data ID  and that's the file name of the cached version  that's sitting in that cached directory.  So a few slides ago, we saw that cached directory  and it looked like a grid or some hash of the file name.  It wasn't the original file name.  Here's where we can actually see  and map that back to its original file name.  So that's the cache data ID is the cached version file name  and then obviously the inode ID, we can look at that  and then reverse engineer that if you will,  looking at the prior databases and find that inode ID  and be able to see the original file name.  And then also we'll get an age column  which gives us the when a file was cached.  Zero, you'll see in that column if it is not cached.  If it is a one, it is cached.  So we'll take a look at that, or I'm sorry, not a one,  but we'll see the UNIX epoch time  of when that file was cached locally.  So in that far right column there,  you'll see a few different date timestamps  when those files were cached  and then all the other ones there  that were not cached locally on the system  that we were with compromised.  Okay, and so with the streamsfs.db database,  if we take a look at that, obviously there,  you can see in the names column of the syncdb  and that's where we can recreate the file name.  So again, going back to the streamsfsdb,  we can see that there's a grid or hash there  of a one, b four, five, et cetera.  That's what we would have seen in the cache directory  if we want to know the original file name.  We go over to the inode ID column, we see that it's 13.  We then open up the syncdb database  and we can look at the inode ID for 13,  which then go into the left-hand side there.  We can see in the names column, it was called business plan.  So that's how we can recreate those file names  if we do find interesting cached files  sitting in that cache directory.  And here's just another example of a cached item  that we can open up in the cache directory  and we can see the magic byte of PK.  And essentially we can see that that is a docx document  so we can open up that in Microsoft Word  or change the file extension to docx and open it that way.  And here we can see obviously I didn't have Microsoft  office installed, but I was able to open it up in WordPad  and we can now see that that is in fact the business plan  for startup business document that we saw.  Okay, and just a couple of things on those columns  within the streamfsdb, we can obviously see  whether it's a file or folder, the parent, inode ID,  the name of the file, we'll see multiple timestamps,  the created at timestamp, the modified timestamp,  access timestamps, again, you may want to do a little bit  of testing on this if that's important to you.  I don't know exactly what events will trigger that  and I just want to warn you of that.  We'll also see the inode ID of the object  we're taking a look at and we'll see whether or not  the item or the object is marked for offline use,  essentially kept offline or cached.  And then we'll also see folder fetch timestamp,  so it's an again, UNIX epoch timestamp  or the last folder sync for that object.  Let's go ahead and talk about Citrix share file  for a second here.  A little intro to it, the application to download,  unlike all the other applications we've talked about,  it's behind a signup wall, so you cannot just go  download it like you would for OneDrive or Dropbox  or anything else like that.  You actually need to register for a trial of it  using what they say a business or enterprise account.  However, I was able to use a Gmail account  for a trial request, instantly got the download link  for that and signed up.  And then upon installing share file,  it what it looks like is it creates a virtual volume,  fat 32, similar to what Google Drive is doing  with FileStream, and it will automatically create  a mounted S drive for you on that Windows system.  For what I see, the databases are SQLite  and they are unencrypted, so yet another unencrypted database.  The key things that I've noted here from testing  is that obviously the S drive or volume  is what the default file store.  We'll see within user profile, there's app data,  local Citrix, and then within Citrix,  you'll see a couple other directories  and files of interest.  Within Citrix files slash DB, there's an ID  and this ID seemed to change,  it was probably based off of my trial.  That seems to be where most of the databases are stored,  so possibly the ID directory is created  so that if you have different share file accounts,  they're stored in different directories.  The remote DB, it appeared to have a list of all files  that were remote and folders as well.  And then we have a local item.db  and that lists all the local files and folders.  There's also a logs directory  and that's where they store all the different log files.  And then there's a Citrix file underscore  and the date.log and that seemed to have detailed activity  about what's going on with share file.  And then I also identified that they had part cache directory  and that seemed to have all of the cache files  that I opened up locally on the window system.  So if we see here the DB directory  and then some ID or GWID number,  that's where we've got all the different databases.  You can see there's more than I mentioned  on the prior slide and the reason for that is  that there are certain databases that were near empty  or didn't seem to be having unique information.  So I kind of left those out.  Within the remote DB, we'll have a couple  of different columns.  If we open that up in a database viewer  for a browser for SQLite, we've got folder IDs,  parent folder IDs, file names and global share file IDs.  So it's a sign of unique ID.  And we can see here the different files  that I had within share file.  We can obviously the name, there's a bunch  of different file names that I had for testing  and then the unique ID to the right of that.  The remote DB database, it's got a object ID in the database.  It has a parent object ID.  It has an identifier for the item,  whether or not if it was a file or folder.  So you can see indications again,  similar to the last example we looked at,  not as detailed as Google Drive,  but at least we can tell if it's a file or folder.  We get a created date and UNIX epoch time.  We have a file hash and quite a few other columns  that didn't seem super relevant for this talk.  So here's just a sample.  You could see there's a lot of different columns here.  Quite a few were gnarled out.  And other ones just didn't seem relevant  for offensive security purposes.  The local item database, we can see things like the key.  There are certain columns here.  I didn't have great explanations for, so I left those blank.  But again, we've got the change date,  last access date, last write date, an ID number,  which not sure how that differs from the share file  unique ID we saw prior.  There's the content ID.  Again, not sure how that differs from the key or the ID.  And then the creation date, time and object  was created in UNIX epoch.  We did get another interesting one,  is there's a URL column.  And that gives us a cloud URL.  So it's the instance ID.  I don't know if this changes for paid accounts  versus trials, but I had some kind of trial instance ID.sf-api.com  slash sf slash v3 slash items.  And then the item ID,  which matched up to the other ID column  that we see here on the screen.  And so I thought that was pretty interesting.  When I went ahead and tried to access that  with a browser, Firefox or Chrome,  it would not give me access to those files.  Now, I would like to do some further testing on that  and figure out if we can use other tools,  aside from a browser,  to go ahead and access those files without authentication.  That seems like it may be a security issue for ShareFile,  but I have not validated that yet.  We also see a file hash  and there's quite a few other columns that we see.  Within the directory entry.db database,  we just get very limited information,  a parent ID of an object, file name, ID of an object.  If we go ahead and take a look at the Citrix files,  underscore date,  and then it actually has the date of the file.log,  we'll see other actions that we may want to parse out,  using strings or grep or something like that.  Upload file, and these are all in brackets.  You want to search for those file system notifier, local,  win, fsp, delete item, download, upload, recall back.  Those are all interesting things  that I found within those log files.  If we go ahead and take a look at that part cache file,  it's exactly the same as we saw in the last example for box,  where in this case though,  it seemed to rename it rather than some type of grid.  The directory, the parent directory  would be some type of grid that or hash  or something that identified that file,  but then within that, it was a single cached file.  It was generally called zero dot part.  However, if you open that up,  and again with a hex editor, you'd see the magic bite,  you see that it's a word doc,  and we could just change the file extension to dot dot x,  and we could go ahead and open up that file,  whether or not it was deleted within share file,  we now have a cached version of that.  So in closing, one other way  that you may be able to take a look at things,  if a user is not actually,  or they have not installed the application,  but they are using cloud file storage solutions,  you want to numerator a little bit about what they're doing.  I identified some things within Google Drive  where if they were using or viewing  or editing Google spreadsheets,  you would see within their browser history,  docs.google.com slash spreadsheets.  If they were editing or viewing a presentation,  you could see docs.google.com slash presentation.  Not a ton of great information from that  other than that they are using Google Docs  in the environment, and you may have to then  attempt to gather documents else or a different method.  But obviously if they are using a browser,  you have access to their browser,  Google never signs you out,  so you should be able to obviously just open a browser  and access the documents there,  but this is a tell tale sign that they are using  probably G Suite or Google Docs for the workplace.  We can also see other tools, for example, Box,  whether they were in the root directory,  it's gonna have app.box.com slash folder slash zero,  and then we will see other indications of different folders,  but at least you can see that they have signed in  and that they were looking at the root of box.com  if you see that folder slash zero.  With OneDrive, you're gonna see OneDrive.live.com  slash question mark ID equal root,  and you'll see that they have a personal account there  and they are looking in the root directory,  you'll also see the CID of their personal OneDrive account.  For business, it's a little bit different.  They're probably gonna be using SharePoint.  If you're using Dropbox,  we can see that it's just Dropbox.com slash home,  which wasn't a great indication  of what they were doing within Dropbox.  With viewing an actual document though,  showing that they have signed in  and they're actually viewing content,  you'll see Dropbox.com slash SCL,  and that will indicate that they have actually  viewed documents within Dropbox.  Also, if they are viewing the contents of a folder,  you're gonna go ahead and actually see the folder name  as well, so it's gonna be Dropbox.com slash home  slash the folder name,  you'll get some indication of the different folders,  whether it's accounting, HR, et cetera.  Now, one thing I did create for you  if you wanna go ahead and shoot me a message  on LinkedIn or Twitter, happy to share this with you.  Once I created my lab environment,  and I wanted to go ahead and collect those,  the metadata and the artifacts that were left behind,  what I did is I created a CAPE target,  and so I utilized CAPE,  which generally I would use more in the instant response  or digital forensic case to do a triage image of a system.  The reason that I like using this tool  is that you can see here using this custom target  that I created, it took 12 seconds,  just under 12 seconds to go ahead and collect all that data.  So if you wanna play around with this  or try and test this out,  see what kind of CAF files are left behind  or that you can enumerate, it's very easy to do.  You can obviously pull these yourself,  but I found it useful to use a CAPE target  so that I could just collect all of the different data  from the different cloud providers very quickly.  And so I've got to snip it there.  I can give you the GitHub link  if you go ahead and send me a message on LinkedIn  or Twitter as I mentioned.  And that wraps up.
DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_0_71.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_72_947.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_948_1835.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_1836_2351.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_2352_2927.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_2928_6779.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_6780_7643.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_7644_8735.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_8736_10331.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_10332_11555.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_11556_12959.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_12960_13067.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_13068_15719.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_15720_16007.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_16008_18971.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_18972_20339.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_20340_21443.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_21444_21659.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_21660_22919.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_22920_23123.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_23124_23735.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_23736_24011.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_24012_24167.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_24168_24275.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_24276_25283.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_25284_26063.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_26064_27299.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_27300_28079.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_28080_29483.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_29484_31487.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_31488_33083.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_33084_33191.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_33192_33935.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_33936_35603.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_35604_36935.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_36936_37247.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_37248_37403.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_37404_39911.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_39912_40127.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_40128_40895.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_40896_41807.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_41808_42671.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_42672_43115.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_43116_43259.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_43260_44207.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_44208_44927.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_44928_45263.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_45264_46787.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_46788_48227.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_48228_48923.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_48924_50051.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_50052_51743.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_51744_51791.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_51792_54635.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_54636_55763.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_55764_56303.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_56304_57167.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_57168_57491.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_57492_57767.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_57768_57851.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_57852_59231.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_59232_59519.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_59520_61007.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_61008_61463.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_61464_62711.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_62712_63191.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_63192_63491.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_63492_64619.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_64620_64751.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_64752_65975.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_65976_67775.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_67776_68219.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_68220_68651.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_68652_68927.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_68928_69707.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_69708_69971.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_69972_72095.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_72096_72311.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_72312_73031.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_73032_74063.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_74064_77591.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_77592_78299.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_78300_78539.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_78540_79151.png DEF_CON_Safe_Mode_Red_Team_Village_-_Michael_Wylie_xUbKyFw-lds_79152_79201.png