 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 GCGems on a file server. These days, we seem to be doing at Richie Mae 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 this, 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 have compromised, 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 be 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 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 it 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 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. It adds 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 mandient 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. 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 ADAP and INI file. And those two files, it's going to start the actual file names 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, we'll 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 profile 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 sync diagnostics file. And the other one I'm gonna call the details sync diagnostics file. And now what I've noticed is that if I install Office 365 OneDrive and I look at the sync diagnostics 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 sync diagnostics 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 sync diagnostics 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, bat, 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 sync diagnostics file. It's not as verbose. You have statistical data, 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 sync diagnostics 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 sync diagnostics, 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. 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, 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. And 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 was 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 a required field 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. And 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 is upgrade available 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 HKEyCurrentUser, Software SyncGyns, 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 reg query 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 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 sock 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 subkey 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 subkey 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, get 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, 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 hit call on 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. Sort of looks 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 time, so just keep that in mind. And the ACL roll 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 in DB browser for SQLite, all the columns I was talking about. And then our synclog.log file, it's insight into user's 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 name you're looking for. So if there's a specific file name or you wanted to do a wild card 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 used 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 wanna do this trying to figure out what's going on or every use case is gonna 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 gonna 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 gonna 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 snapshots.db 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 in the screen 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 the 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 the 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 gonna send it to the local recycle bin and Windows machines and that does not get purged. So unless obviously the user purchased it, whereas on the cloud, it's going to, if a user delete something, it goes to the cloud recycle bin and trash can and it's gonna 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 recycling bin. So if you are looking for something, I do encourage you to look in the recycling 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 toolkits out there. There are PS1 files of 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 forget hub, 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 cached. So you can dig into that without decrypting the databases. Anything else though that the filecache.dbx, there are some duplicate directories as far as, not directories, but databases host.db and host.dbx. They look similar to 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. You know, I can get in there from my testing, those were still unreadable. The other thing you can find is 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 a tiny bit of information from that. But Dropbox really, I liked that they did 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 in the store 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 underscore 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 on 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 underscore 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 look like grid, possibly a hash filenames. 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 notepad's 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 that you, as 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 filenames, test.txt, when content was created, again, in Unix epoch time. And then we've got that database directory with a couple of those databases we've talked about. In 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 ID, so 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 shop one hash within box. We see when the file is 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 don't want to 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 when 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 streamsfs.db, 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 could 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 stream fsdb, 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 for 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, FAT32, similar to what Google Drive is doing with FileStream. And it will automatically create a mounted S drive for you on that window system. From 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 they, 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 directories 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 dot 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 then a date dot 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 were 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 ID. So it's a sign of unique ID. And we can see here the different files that I had within share file. We're gonna see 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 just 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 and 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 share file, 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 dot log. We'll see other actions that we may wanna parse out using strings or grep or something like that. Upload file, and these are all in brackets. You wanna 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. And if we go ahead and take a look at that part cache file, it's exactly the same as we saw on 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. And it was generally called zero dot part. However, if you open that up and again with a hex editor, you'd see the magic byte. 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 that 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 files for solutions, you wanna enumerate 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 and 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 telltale 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, you 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're 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 than 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 a snippet 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.