WEBVTT 00:00.000 --> 00:01.760 Cloud File Storage Gems. 00:01.760 --> 00:07.020 I'm Michael Wiley, Director of Cybersecurity Services at Richie May Technology Solutions. 00:07.020 --> 00:17.060 Prior to joining the firm, I owned a boutique cybersecurity firm in Los Angeles, California, where I performed penetration tests, red team engagements, phishing campaigns, social engineering, and so on. 00:17.140 --> 00:23.040 These days, I do a bit more around compliance, digital forensics, incident response, and security architecture. 00:23.540 --> 00:30.420 I've got plenty of certifications I've collected over the past few years, and I enjoy what I do tremendously. 00:30.860 --> 00:34.740 I encourage you to connect on LinkedIn and follow me on Twitter. 00:34.740 --> 00:38.060 Those are probably the best two ways to get a hold of me after this talk. 00:38.600 --> 00:39.940 About Richie May. 00:40.220 --> 00:45.580 Well, the firm was founded 30, going on 35 years ago, as a tax and audit firm. 00:45.580 --> 00:54.520 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. 00:54.920 --> 00:57.740 They brought in my boss, who's a former CISO. 00:58.320 --> 01:02.500 They acquired my firm and a couple of others to build the team that I work with today. 01:02.800 --> 01:08.020 I focus on the media and entertainment industry, while the firm's other niche is the financial sector. 01:08.020 --> 01:12.900 So I get to work with a lot of studios and vendors that make the movies you love happen. 01:13.920 --> 01:16.340 Some of the learning objectives we're going to go over in this talk. 01:16.340 --> 01:20.940 We're going to learn what file artifacts are available in cloud file storage applications. 01:20.940 --> 01:26.600 We'll see what kind of cloud file storage user activities we can enumerate during a penetration test. 01:26.600 --> 01:34.240 We'll be introduced to application logs and what's available there and examine the difference between cloud file storage providers. 01:34.720 --> 01:37.540 So first, I want to give some credit where credit is due. 01:37.760 --> 01:46.780 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. 01:46.780 --> 01:54.180 So just name a few of those who have created content and things that I have read, come across, looked at their research labs, etc. 01:54.260 --> 01:56.460 These people are due credit. 01:58.100 --> 02:00.920 So why are we talking about cloud file storage solutions? 02:00.920 --> 02:08.760 Well, back in the day, obviously, we had file servers on premise and that's the most of the time the crown jewel is what we're looking at during a test. 02:08.800 --> 02:15.000 It could be obviously a database or something else, but a lot of times you're going to find those juicy gems on a file server. 02:15.280 --> 02:29.780 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, 02:29.780 --> 02:30.960 Sharefile, etc. 02:31.400 --> 02:40.040 And so some of the perceived benefits that organizations get of this and why they're making that transition is that, one, there's protection against disasters for the most part. 02:40.040 --> 02:43.980 So whether it's the pandemic, you can go home and obviously access Google Drive. 02:43.980 --> 02:48.760 Whereas if you had a file server on premise, you'd obviously need VPN access or some other way to get to those files. 02:49.080 --> 02:51.140 There's a decrease in maintenance. 02:51.140 --> 02:54.520 So IT departments don't have to sit there and patch file servers. 02:54.520 --> 02:56.240 They don't have to work on ACLs. 02:56.240 --> 03:01.760 They don't have to troubleshoot DFS issues, sync problems, all those kinds of things. 03:02.180 --> 03:04.800 There's also perceived a high availability aspect of it. 03:04.800 --> 03:13.040 Sure, cloud can go down from time to time, but for the most part, these cloud file storage solutions have an uptime higher than file servers that are sitting on premise. 03:13.040 --> 03:14.460 They're also scalable. 03:14.460 --> 03:22.760 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. 03:22.760 --> 03:34.400 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. 03:34.540 --> 03:36.760 Also, there's some ease of management. 03:36.760 --> 03:43.720 You don't have to get into a Windows operating system and adjust file permissions or folder permissions or share permissions. 03:43.720 --> 03:47.420 You can just basically make a couple of changes from a web interface. 03:47.980 --> 03:50.360 There are a couple uses that we're going to take a look at. 03:50.360 --> 03:57.920 And so if you do end up compromising a system and you suspect or see that there is a cloud file storage solution there, you may run into one of two scenarios. 03:57.920 --> 04:01.020 One, it may be business authorized. 04:01.020 --> 04:05.880 So there may be a cloud file storage solution that the business has paid for, implemented and deployed. 04:06.000 --> 04:12.440 And there may be some differences then if you find the application installed, but it's a personal account that they have logged in with. 04:12.440 --> 04:30.660 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. 04:31.660 --> 04:33.880 So what are those different solutions out there? 04:33.880 --> 04:40.020 Well, we're going to talk about Microsoft OneDrive, Google Drive, Dropbox, Box and Citrix ShareFile. 04:40.020 --> 04:53.320 And the data here was pulled up from, I believe it was SolarWinds did a study on this, and they outlined small, midsize or large businesses and which solution they're using. 04:53.320 --> 04:59.500 So you can obviously see Microsoft OneDrive, it's baked into Windows 8 and above, so a lot of people are using it. 04:59.500 --> 05:05.820 But when you start getting into some of the other solutions like Box, you can obviously see they're focusing on larger businesses in that market share. 05:07.100 --> 05:10.820 So as I mentioned, there's two different scenarios that we might run across. 05:10.820 --> 05:19.700 One is where the remote system that we've compromised, they're running a cloud file storage solution that is sanctioned by the corporate environment. 05:19.700 --> 05:27.300 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. 05:27.300 --> 05:43.280 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. 05:43.280 --> 05:49.580 And that may bypass some of those shadow IT or security controls that the defenders put in place. 05:50.140 --> 06:00.140 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? 06:00.140 --> 06:07.300 Well, if you think of cloud file storage solutions as replacements of file servers, we may see customer data, financials, employee data, HR. 06:07.300 --> 06:15.020 You wouldn't believe some of the things that I have seen people store in cloud file storage solutions and with lax security around them. 06:16.100 --> 06:21.720 Some of the things that these cloud file storage applications may leave behind that are of interest to us, cached files. 06:21.720 --> 06:33.120 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. 06:33.260 --> 06:39.480 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. 06:39.480 --> 06:43.920 So we can see what is out there that maybe the user doesn't have stored locally. 06:44.480 --> 06:49.120 We'll see file usage and their behavior around those files, what files they're accessing most frequently. 06:49.120 --> 06:52.880 We'll be able to find traces of possibly deleted files as well. 06:53.460 --> 06:59.740 So as I mentioned, there is either a business or enterprise account and that may be company issued. 06:59.740 --> 07:07.180 There may be additional logging and security controls that the security team or IT team has, such as CASB. 07:07.520 --> 07:12.200 There's also more logging generally in the cloud if it is a business or enterprise account. 07:12.200 --> 07:20.820 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. 07:20.860 --> 07:25.900 There may be no access to the actual account itself. 07:25.900 --> 07:33.820 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. 07:33.820 --> 07:39.820 There's no central visibility by the defenders though, so they're not going to see the things we're poking around or accessing. 07:40.420 --> 07:43.220 And then we're also going to be able to find some local logs there. 07:43.220 --> 07:51.940 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. 07:51.940 --> 07:58.020 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. 07:58.240 --> 08:03.200 It's not exactly called that, we'll get into that in a second, but 15 gigs of free space there. 08:03.200 --> 08:11.020 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. 08:11.360 --> 08:15.580 With Office 365, it comes with OneDrive subscription there. 08:15.900 --> 08:18.880 OneDrive Basics, the free alternative with only five gigs. 08:18.880 --> 08:25.160 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. 08:25.800 --> 08:30.160 Dropbox Pro, the equivalent for a free account is Box Starter. 08:30.220 --> 08:34.280 This may have changed since I built this slide a while back. 08:34.440 --> 08:36.840 It used to be able to get about a hundred gigs of space. 08:36.840 --> 08:38.640 I think they have limited that. 08:39.000 --> 08:41.240 So let's talk about Microsoft OneDrive first. 08:41.240 --> 08:42.000 Let's get into it. 08:42.000 --> 08:44.800 That's the one that's baked into Windows 8 and above. 08:44.960 --> 08:46.700 It must be enabled. 08:46.700 --> 08:49.700 So it's installed, but you need to enable it via authentication. 08:49.700 --> 08:58.880 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 AppData Local Microsoft. 08:58.880 --> 09:04.880 So that folder will not be there, that directory will not be there until you authenticate with the OneDrive application. 09:05.520 --> 09:15.200 Now, if you have a personal account, you're going to see within AppData Local Microsoft OneDrive logs, you're going to see a personal folder directory. 09:15.680 --> 09:19.760 If they have a business version of OneDrive, you're going to see business one. 09:19.760 --> 09:27.000 Now, I believe the reason they do business one is because that you can install or sign into more than one account. 09:27.000 --> 09:31.240 And so you might see business one, business two, business three, but the primary account should be business one. 09:31.580 --> 09:46.260 With Office 365, the defenders do have a unified logging, and it is by default enabled for my record collection up to 90 days. 09:46.560 --> 09:58.160 Now, from the instance I've been working more recently, and what we see with something 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. 09:58.160 --> 10:03.960 And so that 90 days of retention may not be enough for defenders to see what's going on, especially in the red team engagement. 10:04.960 --> 10:13.720 But even with a personal account, though, there's no central logging from what I can see on the web interface of OneDrive. 10:13.720 --> 10:15.960 So all those logs are stored locally. 10:15.960 --> 10:28.740 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 accessed this, it's a bit limited. 10:29.520 --> 10:37.660 And so on the left-hand side there, we can see in AppData, local Microsoft OneDrive logs, we've got a couple of different logs that are stored locally on the endpoint. 10:38.000 --> 10:40.780 And on the right-hand side, we see the business unified logs. 10:41.280 --> 10:56.580 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 going to go. 10:57.060 --> 11:01.940 If it is a Office 365 or business account, it'll be OneDrive dash and the company name. 11:01.940 --> 11:06.500 So we'll be able to see what company they work for as well and make sure it's obviously in scope. 11:08.240 --> 11:14.320 We'll then see the root directory within the logs directory, which is kind of strange. 11:14.360 --> 11:18.840 We'll also be able to see some metadata for local and cloud files. 11:18.840 --> 11:23.280 So even if the file is not synced locally, we may be able to see it in the sync diagnostics log. 11:23.280 --> 11:25.720 There is a big maybe there I'll talk about in a second. 11:26.180 --> 11:29.540 And then we're going to have a DAT and INI file. 11:29.540 --> 11:32.000 And those two files, it's going to start... 11:32.000 --> 11:36.500 the actual file name is going to be the customer ID or the CID of the user. 11:37.020 --> 11:41.540 So you'll see with the CID.DAT, you'll see a list of local and cloud file names. 11:41.540 --> 11:44.620 So even things that are not synced locally, you'll be able to see those. 11:44.620 --> 11:52.700 And the CID.INI file, we'll be able to see the file store locations, some sync time, usage details, and some other metadata there. 11:52.860 --> 11:59.360 We're going to see another file that starts with the CID of the user, followed by a dash and ProfileServiceResponse.txt. 11:59.380 --> 12:04.140 That will give us the name, email, CID, email, phone, and title, etc. 12:04.140 --> 12:05.360 of the user. 12:05.460 --> 12:08.080 That only is the case, though, for personal accounts. 12:08.080 --> 12:12.900 When I tried it with Office 365 or paid versions, I did not get this file. 12:12.900 --> 12:20.260 I find that interesting because most people aren't going to sign in or add their title and phone number and address and stuff like that. 12:20.280 --> 12:22.680 I'll show you a more detailed version in a second here. 12:23.480 --> 12:28.780 And most of the time, you're going to see that as null, but at least you can see the email address that they have associated with OneDrive. 12:28.940 --> 12:37.200 And then you're going to also find a obfuscationStringMap.txt file, and that's going to be important to map back to obfuscated file names. 12:37.200 --> 12:38.940 And I'll show you how that works in a second, too. 12:39.660 --> 12:45.900 So within the SyncDiagnostics.log file, I have observed two different types of files. 12:45.900 --> 12:48.600 And so you may get one of two versions. 12:48.600 --> 12:52.920 And I think I've narrowed it down, but I haven't had enough test cases to verify this. 12:53.280 --> 13:00.120 I'm going to call one the Summary SyncDiagnostics file, and the other one I'm going to call the Details SyncDiagnostics file. 13:00.140 --> 13:10.800 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. 13:11.340 --> 13:28.260 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. 13:28.260 --> 13:30.080 So that's my theory to this point. 13:30.080 --> 13:32.020 Again, I need more testing for that. 13:33.060 --> 13:34.400 And I'll show you what those look like. 13:34.400 --> 13:43.820 So on the left-hand side here, we've got the Detailed SyncDiagnostics log, and you can see that there's, in the bottom part of that, there's files and folders that are presumably added or synced. 13:43.820 --> 13:53.720 And you can see some type of mount point with possibly a GUID, and then there is a backslash, and then a three-word string. 13:53.720 --> 13:57.480 So far, jump, sue, sue, bat, egg, and so on. 13:57.480 --> 14:03.160 So those are obfuscated file names, and I'll show you how to decode those in a second. 14:03.160 --> 14:06.460 On the right-hand side, you have the summary version of the SyncDiagnostics file. 14:06.460 --> 14:07.960 It's not as verbose. 14:07.960 --> 14:17.460 You have statistical data, sync progress, you've got last sync time, bytes downloaded, bytes uploaded, that kind of stuff. 14:17.460 --> 14:24.460 And so here's, again, a little bit more of the summary version where you could see the number of changed folders, deleted folders. 14:24.460 --> 14:26.700 It's really high-level information there. 14:27.080 --> 14:38.180 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. 14:38.180 --> 14:44.840 And again, all of these files that I'm talking about, with the exception of Dropbox, they are all clear text. 14:44.840 --> 14:47.900 So these files, it's not something special I've had to open up. 14:47.900 --> 14:51.920 The obfuscation string map is just sitting in a directory that anyone can access. 14:52.200 --> 15:05.080 And when we look at the SyncDiagnostics, we're going to have to take that three-word string there, like C, bat, egg, and we're going to have to go map that to our obfuscation string map text file. 15:05.080 --> 15:08.540 And so there we can see that C, bat, egg essentially equals the desktop. 15:08.540 --> 15:13.000 So it looks like a folder was added to Sync, and that folder was desktop. 15:13.180 --> 15:16.520 So it's a little bit of work, but you can go ahead and map those back and forth there. 15:17.720 --> 15:21.580 Just a little bit more on that obfuscation string map text file. 15:21.640 --> 15:24.620 I think that last slide showed it in great detail. 15:26.000 --> 15:33.480 Okay, and then so the CID of the user.dat, if we open that up, that's going to show us the list of file names both locally and in the cloud. 15:33.480 --> 15:38.020 So even if it's not synced to the local file system, we can see what that user has access to in the cloud. 15:38.280 --> 15:41.200 And it is a little bit challenging to read this dat file. 15:41.200 --> 15:43.100 It's not formatted in the greatest way. 15:43.160 --> 15:48.580 So you can open it up in a hex editor, and you can even see searching for strings isn't the best. 15:48.940 --> 16:00.740 However, if you use something like strings or vstrings, 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. 16:02.100 --> 16:06.480 Okay, and in the business version, though, of the CID.dat file, it's a little bit different. 16:06.480 --> 16:11.360 So obviously this last one here was the personal version, and we were able to easily see those directory names. 16:11.380 --> 16:15.940 With the business version, though, it's a little less apparent. 16:16.040 --> 16:23.440 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 GWT there. 16:23.440 --> 16:40.740 And so when I thought maybe it was obfuscated, and if I just open up that obfuscation string map text file and correlate that or cross-reference it, I was able to find some hits, but it was more so on the deobfuscation side, and I wasn't really able to go ahead and figure out what those file names were. 16:40.740 --> 16:45.480 So it may also be an MD5 hash or some type of GWT. 16:45.480 --> 16:51.340 I haven't really been able to figure out how on the business version to see all the file names. 16:52.620 --> 17:02.360 Okay, so with Microsoft OneDrive, the CID.ini file, as I mentioned, it's going to be a couple of different variables that you're going to see in there depending if it's personal or business. 17:02.360 --> 17:11.680 But essentially what you are going to be able to see is the CID of the user and the location, the URL of OneDrive for that user. 17:11.680 --> 17:15.700 You'll be able to see the last time they synced in Unix Epoch time. 17:15.700 --> 17:22.800 You'll be able to see the sync activity, bytes transferred, so you can see how active they are using OneDrive. 17:24.300 --> 17:29.940 The CID-ProfileServiceResponse file, that one gives us a plethora of information. 17:29.940 --> 17:34.800 However, I have not seen this file get created for business or Office 365 accounts. 17:34.800 --> 17:37.620 It only seems like it's for personal accounts. 17:37.740 --> 17:45.320 If you got the personal account, though, as I mentioned, you're going to see the display name, first name, last name, CID, email address, phone number, title, address, and so much more. 17:45.500 --> 17:56.180 However, a lot of those things like job title, when I created my sock bucket account here for OneDrive, it did not ask me for a title or address or phone number. 17:56.180 --> 18:00.000 So maybe a user would go into their profile and update that stuff. 18:00.000 --> 18:05.700 But by default, that's not a required field to create a OneDrive account or a live account. 18:05.700 --> 18:07.900 And so I did not need to do that. 18:07.900 --> 18:08.800 Therefore, I didn't fill it out. 18:08.800 --> 18:11.080 And that's why you're going to see a lot of null fields there. 18:12.560 --> 18:21.460 So when I did a red shot and I took a look at what registry keys are being created here by OneDrive, we can see that with the business version, we have quite a few registry keys. 18:21.460 --> 18:22.600 With personal, it's less. 18:22.600 --> 18:24.640 And then I did a difference on those. 18:24.800 --> 18:29.100 And so the difference is that... or the common is all the way on the right-hand side. 18:29.100 --> 18:38.180 And then the registry keys that the personal account had that the business did not have is going to be the IsUpgradeAvailable and VaultShortcutPath. 18:38.400 --> 18:43.360 Otherwise, the keys that the personal account had were similar to the business account. 18:44.480 --> 18:53.620 So the other cool thing you're going to see if you look at the registry hive, and you can take a look within HKeyCurrentUser, Software, Sync Engines, Providers, OneDrive. 18:53.620 --> 19:00.880 On a business account, if you look in there, you possibly are going to see some different random characters. 19:00.880 --> 19:03.300 It may be a CID or a GUID. 19:03.480 --> 19:10.760 But essentially, when you look at that, those are items that are shared with the user that you are enumerating. 19:10.800 --> 19:16.660 And so what that tells me is that they have received shared files from another user within OneDrive. 19:16.780 --> 19:24.680 If you actually do a reg query on any one of those, you're going to go ahead and then get more details about that, such as what the actual share name is. 19:24.680 --> 19:30.660 And so we can see there on the amount point, it is where it's located, and it also tells us the name. 19:30.660 --> 19:33.180 So it was called something project documents. 19:34.440 --> 19:38.380 And then we actually get the URL namespace for that as well that we can go ahead and try. 19:39.260 --> 19:46.400 Now, one thing about this, whether it's personal or business, that I've noticed is that you will have to accept the share. 19:46.400 --> 19:52.620 So if someone just shares it for you and you see it in OneDrive online, it doesn't mean that you're going to see that registry key here created. 19:52.620 --> 19:55.560 What happens is you have to click the add share. 19:55.560 --> 20:04.280 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. 20:04.280 --> 20:14.720 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. 20:14.720 --> 20:17.420 And once I click add, that's when that was created. 20:17.420 --> 20:25.440 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. 20:25.440 --> 20:32.900 Just as soon as you go into the OneDrive key, you're going to see there's the sub key called test and that was added there. 20:32.900 --> 20:39.880 So rather than creating that CID or some unique ID for the share, it's going to have the actual name of the share in there. 20:40.280 --> 20:47.480 And then if you actually go into that sub key of test, you're going to go ahead and see the CID of the user that shared it. 20:47.480 --> 20:51.440 So you won't get their email address or username, but you will actually see the CID. 20:51.440 --> 20:59.380 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. 21:00.740 --> 21:03.640 So Microsoft also has this feature called Space Saver. 21:04.660 --> 21:08.300 And so what they do with Space Saver is that they back... let me start again... 21:08.300 --> 21:23.880 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 was kind of a pain if you had nested folders and you only wanted certain things synced. 21:23.980 --> 21:34.280 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. 21:34.280 --> 21:40.240 And so a lot of these cloud file storage solutions have adopted the philosophy of caching files. 21:40.280 --> 21:48.540 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. 21:48.540 --> 21:50.760 Unless you open them, they're going to pull them down. 21:51.200 --> 21:54.260 So in Dropbox, for example, they have Smart Sync. 21:54.260 --> 21:55.720 It's a similar type of feature. 21:55.980 --> 21:59.580 If you've ever looked at OneDrive, you see those different icons on the status. 21:59.580 --> 22:03.480 That's telling you if it's cloud only, always local, or cached locally. 22:04.640 --> 22:07.780 So let's now talk about Google Drive. 22:08.500 --> 22:16.580 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 going to be called Backup and Sync. 22:16.580 --> 22:19.700 With Business, they have migrated that over. 22:19.700 --> 22:24.700 So if you have G Suite, what they're going to use is a tool called Drive File Stream. 22:24.920 --> 22:38.020 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. 22:38.020 --> 22:48.740 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. 22:48.740 --> 22:52.180 So it's almost like a mounted drive if you were a network share. 22:53.280 --> 23:07.520 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 on the web version, it's going to download that, but you can see the size there of one kilobyte. 23:07.520 --> 23:10.120 It's super small in Windows Explorer. 23:10.120 --> 23:19.820 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. 23:19.820 --> 23:27.540 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. 23:27.560 --> 23:37.980 And so a couple of cool things is just looking at that, if you open it up in 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. 23:37.980 --> 23:43.700 You'll see the ID, which isn't super relevant, but you also could see the email address associated with that, which is kind of cool. 23:45.040 --> 23:58.560 Some of the other files and folders and databases and stuff that we'll see, we'll be able to see in the sync-config.db, we'll see the user info, their preferences, initial application, install information, so when they installed Google Drive. 23:58.560 --> 24:06.540 In the cloud-graph.db database, we'll see metadata for local cloud and shared files and folders, which is cool. 24:06.660 --> 24:12.960 sync-log.log is files added, deleted, modified, renamed within Google Drive. 24:12.960 --> 24:18.000 The snapshot.db database has local file metadata within it. 24:18.000 --> 24:26.200 The content-cache directory has local file caches for G Suite users only. 24:26.200 --> 24:29.640 So we can actually see content that possibly had been deleted. 24:29.820 --> 24:37.380 And then within the metadata-underscore-sqlite-underscore-db, we'll see offline files, cloud, and deleted file metadata. 24:38.480 --> 24:40.660 So we look at that sync-config database. 24:40.660 --> 24:44.220 There's a couple of things just to look at to identify who the user is. 24:44.220 --> 24:50.660 We can see their user email address and some of the sync time, the application version, see if there's any vulnerabilities with that. 24:50.660 --> 24:55.780 Sort of looks something like this if you open it up with db-browser for SQLite. 24:56.580 --> 25:05.600 And within the cloud-graph database, we'll see things like the Google Drive document IDs, which are unique file and folder object IDs. 25:06.100 --> 25:09.920 We'll see file names, the original or human-readable file names. 25:09.920 --> 25:13.340 We'll see the time when the file was added to Google Drive. 25:13.340 --> 25:18.120 Most of the stuff we're going to take a look at with timestamps, time and date stamps, are going to be in Unix epoch times. 25:18.120 --> 25:19.420 Just keep that in mind. 25:19.420 --> 25:29.580 And the ECL role column, we're going to 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. 25:29.780 --> 25:37.140 And probably the most verbose piece, and more so than any other solution we'll look at, is the doc-type column within this database. 25:37.140 --> 25:44.280 And so if you look at the cloud-graph entry table within this database, that's going to go ahead and give you the doc-type column. 25:44.280 --> 25:55.100 And there you're going to see different numeric values, and those are going to tell you whether the object you're looking at is a folder, a traditional file, so let's say a PDF or Microsoft Word document. 25:55.200 --> 26:01.900 And then the numbers 2 through 13 are reserved for Google native files. 26:01.900 --> 26:07.840 So it'll actually tell you whether or not it was a Google native presentation, which would be a number 2. 26:07.840 --> 26:10.960 4 would be a Google native spreadsheet, so Google Sheets. 26:10.960 --> 26:17.640 And then 6 would tell you if it's a Google Word document, essentially, if it's a native Google Word document. 26:18.000 --> 26:26.060 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. 26:26.120 --> 26:28.360 And then Google also gives you an MD5 hash. 26:28.360 --> 26:37.000 Most of the other solutions will give you a SHA-1 hash, but Google gives you the MD5 hash of that file that you're looking at, which could be useful in certain situations. 26:37.960 --> 26:45.220 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. 26:46.120 --> 26:52.160 And then our synclog.log file is insight into user's activity and their personal accounts. 26:52.160 --> 27:09.400 So whether they are creating files, deleting files, modifying files, renaming files, changing files, and so on, changing ownership, it is a bit messy and convoluted, so I do recommend you either grep it out or you put it in some type of sim where you can manipulate the data and get what you're looking for. 27:09.400 --> 27:15.600 I do recommend grepping or parsing for those keywords as action.create, action.delete to try and find things for you. 27:16.880 --> 27:20.240 The synclog.log will also give us other things about direction. 27:20.240 --> 27:30.520 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. 27:31.120 --> 27:39.120 And then the other thing you can grep for or parse for is name equals you and then semi-quotes around the file name you're looking for. 27:39.120 --> 27:52.760 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. 27:53.440 --> 27:55.880 Okay, and here's just an example I wanted to show you. 27:55.880 --> 28:03.240 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. 28:03.240 --> 28:08.800 In this case, we can see that there was 22 download actions that were taken. 28:08.800 --> 28:16.380 So something was pulled from Google Drive to the local system and you could just kind of get a count on the different activities there. 28:16.380 --> 28:27.300 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. 28:28.080 --> 28:30.540 The snapshot.db, we're going to get all kinds of stuff here. 28:30.540 --> 28:34.680 There's another database that we just looked at prior that was very similar. 28:34.680 --> 28:40.940 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. 28:40.940 --> 28:44.860 So that's some additional functionality we get with the snapshots.db database. 28:45.860 --> 28:50.620 Here's a screenshot of what that would look like if you're looking at it with DB Browser for SQLite. 28:51.160 --> 28:59.440 Now one thing you can do is you can recreate the folder structure that the user would be seeing within Google Drive here. 28:59.440 --> 29:07.420 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? 29:07.780 --> 29:23.280 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. 29:23.280 --> 29:41.120 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 or whatever you're looking at there, but you'd see that there's a document called finance or a document called the Mike Wiley something. 29:41.860 --> 29:56.520 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. 29:57.540 --> 29:59.600 Let's go ahead and take a look at Dropbox real quick. 29:59.600 --> 30:10.180 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. 30:10.180 --> 30:17.140 So kudos to Dropbox, since 2011, they've been using encrypted SQLite databases. 30:17.140 --> 30:21.740 So they're using SQLite encryption extension, SCE, since 2011. 30:21.800 --> 30:36.840 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. 30:37.040 --> 30:42.640 Now the key is stored in registry and it's encrypted using Windows Data Protection API, DPAPI. 30:43.180 --> 30:45.640 And so there's a couple of options. 30:45.640 --> 30:47.860 You can either brute force the password, good luck. 30:48.000 --> 30:55.660 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. 30:55.760 --> 30:59.460 You could also then extract DPAPI from memory. 30:59.460 --> 31:03.320 There is another talk about that, where this worked. 31:03.320 --> 31:13.580 I tried to follow some of the stuff from the DEC WinDB toolkit to extract those keys, but I didn't have success with that in the limited time I had for testing. 31:13.860 --> 31:20.220 So what you can do is look at some of the Dropbox.cache files. 31:20.220 --> 31:26.580 Those contain miscellaneous temporary cache files that possibly were deleted by other users. 31:26.580 --> 31:33.220 I was able to get to some of that stuff without obviously having to get through encryption or find the decryption keys. 31:35.640 --> 31:39.720 The deleting on files that are local. 31:39.720 --> 31:48.580 So if you go ahead and delete something, it's going to send it to the local recycle bin on Windows machines, and that does not get purged, unless obviously the user purges it. 31:48.580 --> 31:59.420 Whereas on the cloud, if a user deletes something, it goes to the cloud, recycle bin, or trash can, and it's going to sit there for 30 to 120 days depending on their subscription level and how much they're paying. 31:59.600 --> 32:02.380 But locally, though, it could still be sitting in a recycling bin. 32:02.380 --> 32:05.520 So if you are looking for something, I do encourage you to look in the recycling bin. 32:05.520 --> 32:08.400 And if they haven't cleared that, you may be able to see purged things there. 32:10.060 --> 32:17.860 And so those encryption keys, as we were talking about, give the different locations on the screen here of where you can find that. 32:17.900 --> 32:27.320 Now, Nicholas and Florian did a talk called A Critical Analysis of Dropbox Software Security at HackLU in 2012. 32:27.360 --> 32:30.100 I recommend taking a look at that. 32:30.100 --> 32:36.600 If you are more interested in this, they were able to get into Dropbox databases. 32:36.740 --> 32:42.240 I did try some of the stuff that they talked about and some of the toolkits out there. 32:42.240 --> 32:51.100 There are PS1 files, so PowerShell scripts, as well as I believe they were Python scripts, and neither of them really worked for me. 32:51.100 --> 32:52.780 So I got different errors. 32:52.780 --> 32:56.240 I tried debugging for a while and eventually moved on to the next tool. 32:56.240 --> 32:58.660 So it has been done, can be done. 32:58.900 --> 33:01.660 If you are really interested, I encourage you to go check that out. 33:01.660 --> 33:07.180 Again, A Critical Analysis of Dropbox Software Security at HackLU 2012. 33:07.180 --> 33:09.420 I believe there's a YouTube video out there on this. 33:09.980 --> 33:15.600 This is allegedly, you can go to the GitHub, play with it yourself, but you should be able to if you tweet that a little bit. 33:15.600 --> 33:17.620 And if you do, please let me know on LinkedIn or Twitter. 33:17.640 --> 33:20.420 I'm curious on what you had to do to get it to work. 33:20.420 --> 33:21.640 Probably something simple. 33:22.620 --> 33:27.560 Some of the files and folders and databases that were created when I installed Dropbox. 33:27.560 --> 33:34.700 We can see that there are the Dropbox cache and the .Dropbox files that are temporary files that are possibly opened or cached. 33:34.700 --> 33:38.380 So you can dig into that without decrypting the databases. 33:38.940 --> 33:53.800 Anything else though, like the FileCache.dbx, there are some duplicate directories as far as, not directories, but databases, Host.db and Host.dbx, they look similar, just slight difference in the extension type. 33:53.800 --> 33:55.820 I could not access either one of them. 33:55.820 --> 34:01.980 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. 34:01.980 --> 34:05.160 From my testing, those were still unreadable. 34:06.700 --> 34:16.080 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 setting, subscription level and type, how much they're paying. 34:16.220 --> 34:29.980 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 decrypting those databases. 34:29.980 --> 34:31.320 So kudos to them again. 34:32.040 --> 34:34.000 Let's take a look at some of the box files. 34:34.080 --> 34:39.860 So obviously you'll find the default file store, but probably one of my favorites is the cache directory. 34:39.860 --> 34:47.020 And within the cache directory, you're going to find full copies of files that were previously opened by the user locally. 34:47.020 --> 35:03.020 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. 35:03.020 --> 35:09.920 And so I have tried in lab environments when I had deleted the files in box and the cache copy is still in the cache directory. 35:10.020 --> 35:12.500 Now the file name will not be the existing file name. 35:12.500 --> 35:25.340 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. 35:25.580 --> 35:32.920 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. 35:32.920 --> 35:38.800 We'll find the box UI underscore some random number underscore the date.log. 35:38.800 --> 35:43.020 And that is going to be generally things associated with the box application. 35:43.020 --> 35:48.180 So when the user signs into the local application, they sign out, network activity. 35:48.300 --> 35:52.480 It's a very detailed user interface logging. 35:52.480 --> 35:53.820 I'll call it that. 35:53.860 --> 35:59.020 We also see the box underscore stream underscore number and then underscore date.log. 35:59.020 --> 36:06.540 And that's going to have file activity, such as files, paths, level of logging, free space on the volume, et cetera. 36:06.540 --> 36:11.780 It's got a lot of detailed information about files in, out, and activity around them. 36:11.780 --> 36:15.220 The data directory is going to have a path to our databases. 36:15.220 --> 36:21.900 We'll see databases such as the syncdb, streamfs.db, and metrics.db. 36:26.200 --> 36:32.340 So if we take a look at the box underscore streams underscore number underscore the date, and you'll find quite a few. 36:32.340 --> 36:38.320 In my test environment, I had just a handful of files and folders, maybe less than 30 files. 36:38.320 --> 36:43.560 And I was already seeing multiple versions of this log file with different dates on them. 36:43.560 --> 36:47.500 So it does seem like it rolls over pretty quickly and there's a lot of activity in these files. 36:47.500 --> 36:52.120 We'll see things with key actions, kind of like we saw on prior applications. 36:52.320 --> 37:03.260 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. 37:03.260 --> 37:10.180 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. 37:10.780 --> 37:20.600 If we take a look at the box underscore streams underscore number underscore date dot log, as you can see there, we'll see things like the cache path. 37:20.600 --> 37:25.960 So if that was modified or changed or anything like that, you could see the cache location. 37:25.960 --> 37:28.220 You'll see database paths. 37:28.220 --> 37:30.560 You'll see the mount path, etc. 37:30.560 --> 37:32.220 You'll see a lot of stuff in there. 37:32.520 --> 37:37.440 And my favorite is that, as I mentioned, that box cache directory. 37:37.440 --> 37:43.060 And so you can see there within the directory, we've got these what look like GWT, possibly a hash, file names. 37:43.060 --> 37:56.760 It doesn't tell us what the originals were, but if you open them up, what you're going to 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. 37:56.760 --> 38:01.760 And so if we do have a hex editor, opening that up and taking a look at the magic byte is going to be the preferred option there. 38:01.760 --> 38:06.620 And we can actually recreate or view those cache documents, which is great. 38:06.620 --> 38:19.900 The box.u, 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. 38:20.360 --> 38:30.660 The box-version.log there, we can see that there are some file names, test.txt, when content was created, again, in Unix epoch time. 38:31.220 --> 38:36.660 And then we've got that database directory with a couple of those databases we've talked about in the sync.db database. 38:36.660 --> 38:40.540 We're going to have a ID of objects or files, folders within box. 38:40.540 --> 38:42.840 We're going to have a type, whether it's a file or folder. 38:42.840 --> 38:49.220 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. 38:49.220 --> 38:54.080 We can then see the parent ID so we can recreate the folder structure within box. 38:54.240 --> 38:58.640 The file name, we get the owner ID of whoever owns that file. 38:58.640 --> 39:02.740 So if someone else owns that file, we should see the owner ID of that user. 39:03.260 --> 39:05.480 We will see a hash in this case. 39:05.480 --> 39:07.760 Unlike other applications, we saw an MB5 hash. 39:07.760 --> 39:09.800 We'll see a SHA1 hash within box. 39:10.300 --> 39:14.120 We see when the file was created, updated. 39:14.120 --> 39:24.160 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. 39:24.160 --> 39:29.020 So that's a little bit more research or something you may want to take a look at and not just trust those dates out of the box. 39:29.880 --> 39:31.060 No pun intended. 39:31.060 --> 39:33.900 Sync.db within that database. 39:33.900 --> 39:36.840 As I mentioned in the last slide, we've got those different fields. 39:36.840 --> 39:41.040 Here's an example of what you might see if you open it up in DB Browser for SQLite. 39:41.200 --> 39:44.960 The streamfsdb, there we're going to see a touch sequence. 39:44.960 --> 39:50.580 I could not find documentation or really reverse engineer what that was doing. 39:50.580 --> 39:58.760 We see a cache data ID and that's the file name of the cached version that's sitting in that cache directory. 39:58.760 --> 40:05.440 So a few slides ago, we saw that cache directory and it looked like a grid or some hash of the file name. 40:05.440 --> 40:06.840 It wasn't the original file name. 40:06.840 --> 40:10.980 Here's where we can actually see and map that back to its original file name. 40:10.980 --> 40:16.240 So that's the cache data ID is the cached version file name. 40:16.480 --> 40:27.920 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. 40:27.920 --> 40:32.000 And then also we'll get an age column, which gives us the when a file was cached. 40:32.260 --> 40:35.740 Zero, you'll see in that column, if it is not cached. 40:35.900 --> 40:39.800 If it is a one, it is cached. 40:39.800 --> 40:46.940 So we'll take a look at that, or I'm sorry, not a one, but we'll see the epoch, Unix epoch time of when that file was cached locally. 40:46.940 --> 40:58.560 So on 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've compromised. 41:00.120 --> 41:00.460 Okay. 41:00.460 --> 41:13.740 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. 41:13.740 --> 41:23.780 So again, going back to the streamsfsdb, we can see that there's a GWT or hash there of A1, B4, 5, et cetera. 41:23.780 --> 41:25.820 That's what we would have seen in the cache directory. 41:25.820 --> 41:29.880 If we want to know the original file name, we go over to the inode ID column. 41:29.880 --> 41:31.040 We see that it's 13. 41:31.040 --> 41:39.580 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. 41:39.580 --> 41:42.240 We can see in the names column, it was called business plan. 41:42.240 --> 41:48.400 So that's how we can recreate those file names if we do find interesting cached files sitting in that cache directory. 41:49.060 --> 41:53.600 And here's just another example of a cached item that we can open up in the cache directory. 41:53.600 --> 41:57.340 And we can see the magic byte of PK. 41:57.480 --> 42:00.420 And essentially we can see that that is a docx document. 42:00.420 --> 42:07.380 So we can open up that in Microsoft Word or change the file extension to .docx and open it that way. 42:08.080 --> 42:13.280 And here we can see, obviously I didn't have Microsoft Office installed, but I was able to open it up in WordPad. 42:13.280 --> 42:19.200 And we can now see that that is in fact the business plan for startup business document that we saw. 42:20.240 --> 42:20.920 Okay. 42:21.020 --> 42:24.700 And just a couple of things on those columns within the stream FSDB. 42:24.700 --> 42:29.820 We can obviously see whether it's a file or folder, the parent's inode ID, the name of the file. 42:29.820 --> 42:35.980 We'll see multiple timestamps, the created at timestamp, the modified timestamp, access timestamps. 42:35.980 --> 42:39.520 Again, you may want to do a little bit of testing on this if that's important to you. 42:39.540 --> 42:44.420 I don't know exactly what events will trigger that, and I just want to warn you of that. 42:44.540 --> 42:47.580 We'll also see the inode ID of the object we're taking a look at. 42:47.580 --> 42:52.360 And we'll see whether or not the item or the object is marked for offline use. 42:53.860 --> 42:57.000 Essentially kept offline or cached. 42:57.000 --> 43:00.160 And then we'll also see folder fetch timestamp. 43:00.160 --> 43:05.140 So it's, again, Unix epoch timestamp or the last folder sync for that object. 43:06.140 --> 43:09.700 Let's go ahead and talk about Citrix share file for a second here. 43:09.700 --> 43:11.160 A little intro to it. 43:11.160 --> 43:17.440 The application to download, unlike all the other applications we've talked about, it's behind a signup wall. 43:17.440 --> 43:24.540 So you cannot just go download it like you would for OneDrive or Dropbox or anything else like that. 43:24.540 --> 43:30.900 You actually need to register for a trial of it using what they say a business or enterprise account. 43:31.280 --> 43:35.280 However, I was able to use a Gmail account for a trial request. 43:35.280 --> 43:38.240 Instantly got the download link for that and signed up. 43:38.760 --> 43:48.140 And then upon installing share file, what it looks like is it creates a virtual volume, FAT32, similar to what Google Drive is doing with FileStream. 43:48.220 --> 43:53.880 And it will automatically create a mounted S drive for you on that Windows system. 43:54.140 --> 43:57.400 From what I see, the databases are SQLite and they are unencrypted. 43:57.400 --> 43:59.840 So yet another unencrypted database. 44:00.240 --> 44:08.640 The key things that I've noted here from testing is that obviously the S drive or volume is what the default file store. 44:08.660 --> 44:14.920 We'll see within user profile, there's app data, local Citrix. 44:14.920 --> 44:18.860 And then within Citrix, you'll see a couple other directories and files of interest. 44:18.860 --> 44:23.320 Within Citrix files slash DB, there's an ID. 44:23.320 --> 44:24.560 And this ID seemed to change. 44:24.560 --> 44:27.200 It was probably based off of my trial. 44:27.760 --> 44:30.520 That seems to be where the most of the databases are stored. 44:30.520 --> 44:37.800 So possibly the ID directory is created so that if you have different share file accounts, they're stored in different directories. 44:37.880 --> 44:46.080 The remote DB, it appeared to have a list of all files that were remote and folders as well. 44:46.080 --> 44:51.120 And then we have a local item.db and that lists all the local files and folders. 44:51.260 --> 44:55.140 There's also a logs directory and that's where they store all the different log files. 44:55.180 --> 45:04.100 And then there's a Citrix file underscore and then a date.log and that seemed to have detailed activity about what's going on with share file. 45:04.220 --> 45:11.720 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 Windows system. 45:12.000 --> 45:18.740 So if we see here, the DB directory and then some ID or GWT number, that's where we've got all the different databases. 45:18.740 --> 45:21.700 You can see there's more than I mentioned on the prior slide. 45:22.020 --> 45:29.580 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. 45:30.480 --> 45:39.220 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. 45:39.220 --> 45:44.800 We've got folder IDs, parent folder IDs, file names, and global share file IDs. 45:44.800 --> 45:46.400 So it's assigned a unique ID. 45:46.800 --> 45:51.260 And we can see here the different files that I had within share file. 45:51.460 --> 45:53.060 We can kind of see the name. 45:53.060 --> 45:57.680 There's a bunch of different file names that I had for testing and then the unique ID to the right of that. 45:57.980 --> 46:04.480 The remote DB database, it's got a object ID in the database. 46:04.480 --> 46:06.680 It has a parent object ID. 46:06.740 --> 46:13.700 It has an identifier for the item, whether or not if it was a file or folder, so you can just see indications. 46:13.700 --> 46:19.240 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. 46:19.240 --> 46:22.220 We get a created date and Unix epoch time. 46:22.220 --> 46:28.580 We have a file hash and quite a few other columns that didn't seem super relevant for this talk. 46:29.160 --> 46:30.480 So here's just a sample. 46:30.480 --> 46:32.820 You can see there's a lot of different columns here. 46:32.820 --> 46:39.620 Quite a few were nulled out and other ones just didn't seem relevant for offensive security purposes. 46:39.760 --> 46:48.520 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. 46:48.520 --> 46:59.360 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. 46:59.640 --> 47:03.520 There's a content ID, again, not sure how that differs from the key or the ID. 47:03.700 --> 47:08.300 And then the creation date, time an object was created in Unix epoch. 47:08.300 --> 47:14.800 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. 47:14.800 --> 47:52.800 I don't know if this changes for paid accounts versus trials, but I had some kind of trial instance ID .sf-api.com .sf-v3 .sf-v3 .sf-v3 .sf-v3 .sf-v3 .sf -v3 .sf -v3 .sf-v3 .sf-v3 .sf-v3 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. 47:53.080 --> 47:58.740 That seems like it may be a security issue for share file, but I have not validated that yet. 48:00.160 --> 48:04.260 We also see a file hash and there's quite a few other columns that we see. 48:04.280 --> 48:12.320 Within the directory entry.db database, we just get very limited information, a parent ID of an object, a file name, ID of an object. 48:13.100 --> 48:26.300 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. 48:27.300 --> 48:29.520 Upload file, these are all in brackets. 48:29.640 --> 48:30.920 You want to search for those. 48:30.920 --> 48:38.420 File system notifier, local, win, FSP, delete item, download, upload, read callback. 48:38.420 --> 48:42.200 Those are all interesting things that I found within those log files. 48:42.280 --> 48:52.340 And 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 GWT. 48:53.140 --> 49:00.700 The directory, the parent directory would be some type of GWT or hash or something that identified that file. 49:00.700 --> 49:04.000 But then within that, it was a single cached file. 49:04.320 --> 49:07.300 It was generally called 0.part. 49:07.520 --> 49:10.640 However, if you open that up and put it in with a hex editor, you'd see the magic byte. 49:10.640 --> 49:18.020 You see that it's a Word doc, and we could just change the file extension to .docx, and we could go ahead and open up that file. 49:18.020 --> 49:22.440 Whether or not it was deleted within share file, we now have a cached version of that. 49:23.360 --> 49:34.600 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 enumerate a little bit about what they're doing. 49:35.880 --> 49:50.120 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. 49:50.120 --> 49:55.580 If they were editing or viewing a presentation, you could see docs.google.com slash presentation. 49:55.580 --> 50:06.480 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. 50:06.480 --> 50:18.520 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. 50:18.520 --> 50:24.260 But this is a telltale sign that they are using probably G Suite or Google Docs for the workplace. 50:25.480 --> 50:44.560 We can also see other tools, for example, Box, whether they were in the root directory, it's going to 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, 50:44.560 --> 50:46.460 if you see that folder slash zero. 50:46.800 --> 50:57.380 With OneDrive, you're going to 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. 50:57.380 --> 51:01.320 You'll also see the CID of their personal OneDrive account. 51:01.320 --> 51:03.460 For business, it's a little bit different. 51:04.200 --> 51:06.340 They're probably going to be using SharePoint. 51:07.260 --> 51:14.460 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. 51:14.680 --> 51:28.180 With viewing an actual document, though, showing that they have signed in and they are actually viewing content, you'll see dropbox.com slash SCL, and that will indicate that they have actually viewed documents within Dropbox. 51:29.080 --> 51:34.860 Also, if they are viewing the content of a folder, you're going to go ahead and actually see the folder name as well. 51:34.860 --> 51:38.780 So it's going to be dropbox.com slash home slash the folder name. 51:38.960 --> 51:42.820 You'll get some indication of the different folders, whether it's accounting, HR, etc. 51:44.200 --> 51:50.720 Now, one thing I did create for you, if you want to go ahead and shoot me a message on LinkedIn or Twitter, happy to share this with you. 51:51.060 --> 52:01.160 Once I created my lab environment and I wanted to go ahead and collect the metadata and the artifacts that were left behind, what I did is I created a CAPE target. 52:01.160 --> 52:10.160 And so I utilized CAPE , which generally I would use more in an incident response or a digital forensic case, to do a triage image of the system. 52:10.320 --> 52:21.580 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. 52:21.580 --> 52:30.240 So if you want to play around with this or try and test this out, see what kind of cache files are left behind or that you can enumerate, it's very easy to do. 52:30.240 --> 52:38.920 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. 52:39.300 --> 52:40.800 And so I've got a snippet there. 52:40.800 --> 52:46.960 I can give you the GitHub link if you go ahead and send me a message on LinkedIn or Twitter , as I mentioned. 52:47.120 --> 52:48.000 And that wraps up this session.