[00:00.000 --> 00:05.320]  Cloud File Storage Gems. I'm Michael Wiley, Director of Cybersecurity Services at Richie
[00:05.320 --> 00:09.560]  May Technology Solutions. Prior to joining the firm, I owned a boutique cybersecurity
[00:09.560 --> 00:14.720]  firm in Los Angeles, California, where I performed penetration tests, red team engagements, phishing
[00:14.720 --> 00:19.540]  campaigns, social engineering, and so on. These days, I do a bit more around compliance,
[00:19.540 --> 00:24.560]  digital forensics, incident response, and security architecture. I've got plenty of
[00:24.560 --> 00:30.420]  certifications I've collected over the past few years, and I enjoy what I do tremendously.
[00:30.860 --> 00:35.180]  I encourage you to connect on LinkedIn and follow me on Twitter. Those are probably the
[00:35.180 --> 00:38.060]  best two ways to get a hold of me after this talk.
[00:38.600 --> 00:44.860]  About Richie May. Well, the firm was founded 30, going on 35 years ago, as a tax and audit
[00:44.860 --> 00:49.500]  firm. A while ago, transitioned into business advisory, and during that process, the firm
[00:49.500 --> 00:55.200]  realized that they wanted to advise their clients on technology and cybersecurity. They
[00:55.200 --> 01:00.500]  brought in my boss, who's a former CISO. They acquired my firm and a couple of others to
[01:00.500 --> 01:05.900]  build the team that I work with today. I focus on the media and entertainment industry, while
[01:05.900 --> 01:10.260]  the firm's other niche is the financial sector. So I get to work with a lot of studios and
[01:10.260 --> 01:12.900]  vendors that make the movies you love happen.
[01:13.920 --> 01:16.820]  Some of the learning objectives we're going to go over in this talk. We're going to learn
[01:16.820 --> 01:21.960]  what file artifacts are available in cloud file storage applications. We'll see what kind
[01:21.960 --> 01:27.060]  of cloud file storage user activities we can enumerate during a penetration test. We'll
[01:27.060 --> 01:31.420]  be introduced to application logs and what's available there and examine the difference
[01:31.420 --> 01:34.240]  between cloud file storage providers.
[01:34.720 --> 01:40.120]  So first, I want to give some credit where credit is due. Some of this I have come up
[01:40.120 --> 01:45.080]  with from my own testing, from forensic cases that I've looked at, as well as a lot of
[01:45.080 --> 01:49.660]  reading from other people's work. So just name a few of those who have created content
[01:49.660 --> 01:54.700]  and things that I have read, come across, looked at their research labs, etc. These
[01:54.700 --> 01:56.460]  people are due credit.
[01:58.100 --> 02:02.640]  So why are we talking about cloud file storage solutions? Well, back in the day, obviously,
[02:02.640 --> 02:07.080]  we had file servers on premise and that's the most of the time the crown jewel is what
[02:07.080 --> 02:11.200]  we're looking at during a test. It could be obviously a database or something else, but
[02:11.200 --> 02:15.960]  a lot of times you're going to find those juicy gems on a file server. These days,
[02:15.960 --> 02:20.260]  we seem to be doing at Richie Mae, a lot of migrations, helping customers move away from
[02:20.260 --> 02:24.780]  the traditional model of non-premise file server and trying to utilize some of these
[02:24.780 --> 02:30.960]  cloud file storage solutions like Box, Google Drive, OneDrive, Dropbox, Sharefile, etc.
[02:31.400 --> 02:35.220]  And so some of the perceived benefits that organizations get of this and why they're
[02:35.220 --> 02:39.560]  making that transition is that, one, there's protection against disasters for the most
[02:39.560 --> 02:43.980]  part. So whether it's the pandemic, you can go home and obviously access Google Drive.
[02:43.980 --> 02:47.420]  Whereas if you had a file server on premise, you'd obviously need VPN access or some other
[02:47.420 --> 02:52.640]  way to get to those files. There's a decrease in maintenance. So IT departments don't have
[02:52.640 --> 02:56.860]  to sit there and patch file servers. They don't have to work on ACLs. They don't have
[02:56.860 --> 03:02.960]  to troubleshoot DFS issues, sync problems, all those kinds of things. There's also perceived
[03:03.100 --> 03:07.080]  a high availability aspect of it. Sure, cloud can go down from time to time, but for the
[03:07.080 --> 03:11.780]  most part, these cloud file storage solutions have an uptime higher than file servers that
[03:11.780 --> 03:17.980]  are sitting on premise. They're also scalable. So Google will happily sell you an extra terabyte
[03:17.980 --> 03:22.760]  or two terabytes of space with just an increase in your price of your monthly subscription.
[03:22.760 --> 03:25.960]  Whereas if you have a traditional file server on premise and you're running out of space,
[03:25.960 --> 03:31.560]  you may have to add hard drives to a RAID cluster or add systems to a cluster or whatever
[03:31.560 --> 03:36.860]  mechanism you're using to get more space. Also, there's some ease of management. You
[03:36.860 --> 03:41.880]  don't have to get into a Windows operating system and adjust file permissions or folder
[03:41.880 --> 03:46.100]  permissions or share permissions. You can just basically make a couple of changes from
[03:46.340 --> 03:50.780]  a web interface. There are a couple uses that we're going to take a look at. And so if you
[03:50.780 --> 03:55.440]  do end up compromising a system and you suspect or see that there is a cloud file storage
[03:55.440 --> 04:01.020]  solution there, you may run into one of two scenarios. One, it may be business authorized.
[04:01.020 --> 04:04.900]  So there may be a cloud file storage solution that the business has paid for, implemented
[04:04.900 --> 04:10.100]  and deployed. And there may be some differences then if you find the application installed,
[04:10.100 --> 04:14.080]  but it's a personal account that they have logged in with. So in many cases, I've gone
[04:14.080 --> 04:19.460]  in from both perspectives, offensive or defensive, and we have seen applications installed that
[04:19.460 --> 04:23.540]  were not sanctioned by the organization, but it was either a employee who thought they
[04:23.540 --> 04:27.620]  were doing good or they wanted to just access their files and they downloaded Dropbox or
[04:27.620 --> 04:33.240]  Box or some application and started syncing files. So what are those different solutions
[04:33.240 --> 04:37.300]  out there? Well, we're going to talk about Microsoft OneDrive, Google Drive, Dropbox,
[04:37.300 --> 04:44.770]  Box and Citrix ShareFile. And the data here was pulled up from, I believe it was SolarWinds
[04:45.600 --> 04:52.620]  did a study on this, and they outlined small, midsize or large businesses and which solution
[04:52.620 --> 04:57.900]  they're using. So you can obviously see Microsoft OneDrive, it's baked into Windows 8 and above,
[04:57.900 --> 05:01.140]  so a lot of people are using it. But when you start getting into some of the other solutions
[05:01.140 --> 05:05.820]  like Box, you can obviously see they're focusing on larger businesses in that market share.
[05:07.100 --> 05:12.220]  So as I mentioned, there's two different scenarios that we might run across. One is where the
[05:12.220 --> 05:17.700]  remote system that we've compromised, they're running a cloud file storage solution that
[05:17.700 --> 05:22.900]  is sanctioned by the corporate environment. And in that case, there may be CASB or off-site
[05:22.900 --> 05:27.300]  logs or other security controls where they're monitoring or controlling what's going on.
[05:27.300 --> 05:31.760]  But we may run across the other scenario on the right-hand side there, where there's the
[05:31.760 --> 05:36.640]  sanctioned cloud applications that may have CASB that is not in line or other security
[05:36.640 --> 05:42.600]  controls, but they're also using a personal version of Google Drive or OneDrive or something
[05:42.600 --> 05:48.500]  like that. And that may bypass some of those shadow IT or security controls that the defenders
[05:48.500 --> 05:54.420]  put in place. So what are some of these gems that we may uncover as we see that there is
[05:54.680 --> 05:59.600]  a cloud file storage application on a system we've compromised and what can we get from
[05:59.600 --> 06:04.020]  that? Well, if you think of cloud file storage solutions as replacements of file servers,
[06:04.020 --> 06:08.220]  we may see customer data, financials, employee data, HR. You wouldn't believe some of the
[06:08.220 --> 06:13.940]  things that I have seen people store in cloud file storage solutions and with lax security
[06:13.940 --> 06:18.740]  around them. Some of the things that these cloud file storage applications may leave
[06:18.740 --> 06:24.260]  behind that are of interest to us, cached files. So whether those files are stored on
[06:24.260 --> 06:29.740]  the cloud or local or local, but then they were deleted, we may be able to recover these
[06:29.740 --> 06:33.940]  cached files and actually see or recreate some of those files. We may see the local
[06:33.940 --> 06:38.340]  files, we'll get a database with all the files that are stored locally, but more importantly
[06:38.340 --> 06:42.800]  in the cloud as well. So we can see what is out there that maybe the user doesn't have
[06:42.800 --> 06:47.680]  stored locally. We'll see file usage and their behavior around those files, what files they're
[06:47.680 --> 06:52.880]  accessing most frequently. We'll be able to find traces of possibly deleted files as well.
[06:53.460 --> 06:59.120]  So as I mentioned, there is either a business or enterprise account and that may be company
[06:59.120 --> 07:04.620]  issued. There may be additional logging and security controls that the security team or
[07:04.620 --> 07:11.240]  IT team has, such as CASB. There's also more logging generally in the cloud if it is a
[07:11.240 --> 07:15.480]  business or enterprise account. Whereas if you stumble upon a free account that someone
[07:15.480 --> 07:19.580]  has on a system you've compromised, it may not be company issued, so there may be no
[07:19.580 --> 07:27.240]  knowledge of it. There may be no access to the actual account itself. That may be not
[07:27.240 --> 07:32.740]  synced with Active Directory or LDAP or single sign-on, so we may not be able to gain access
[07:32.740 --> 07:37.520]  to that right away. There's no central visibility by the defenders though, so they're not going
[07:37.520 --> 07:42.100]  to see the things we're poking around or accessing. And then we're also going to be able to find
[07:42.100 --> 07:46.560]  some local logs there. And so the difference between those business enterprise accounts
[07:46.560 --> 07:50.580]  and the personal free accounts is that there's a lot more storage with the business accounts
[07:50.580 --> 07:54.480]  that are built in. Obviously it depends on what you're paying for, but you might have
[07:54.480 --> 07:59.160]  G Suite, the equivalent to a personal account would be Google Drive. It's not exactly called
[07:59.160 --> 08:04.040]  that, we'll get into that in a second, but 15 gigs of free space there. So even if it's
[08:04.040 --> 08:08.460]  not a sanctioned account and someone just installs the Google Drive app, you can have
[08:08.460 --> 08:14.800]  up to 15 gigs of gems you can find there. With Office 365, it comes with OneDrive subscription
[08:14.800 --> 08:20.160]  there. OneDrive Basics, the free alternative with only five gigs. Box, business or enterprise,
[08:20.160 --> 08:23.640]  you can have different levels of storage, but you can also get two gigs of free storage
[08:23.640 --> 08:30.800]  with a basic account. Dropbox Pro, the equivalent for a free account is Box Starter. This may
[08:30.800 --> 08:35.800]  have changed since I built this slide a while back. It used to be able to get about a hundred
[08:35.800 --> 08:41.240]  gigs of space. I think they have limited that. So let's talk about Microsoft OneDrive first.
[08:41.240 --> 08:46.700]  Let's get into it. That's the one that's baked into Windows 8 and above. It must be enabled.
[08:46.700 --> 08:51.320]  So it's installed, but you need to enable it via authentication. So once you sign in,
[08:51.320 --> 08:56.420]  it does a couple of things, add some registry keys, as well as it creates the OneDrive directory
[08:56.420 --> 09:01.700]  sitting in AppData Local Microsoft. So that folder will not be there, that directory will
[09:01.700 --> 09:07.120]  not be there until you authenticate with the OneDrive application. Now, if you have a personal
[09:07.120 --> 09:12.060]  account, you're going to see within AppData Local Microsoft OneDrive logs, you're going
[09:12.060 --> 09:18.700]  to see a personal folder directory. If they have a business version of OneDrive, you're
[09:18.700 --> 09:23.200]  going to see business one. Now, I believe the reason they do business one is because
[09:23.200 --> 09:27.800]  that you can install or sign into more than one account. And so you might see business
[09:27.800 --> 09:31.920]  one, business two, business three, but the primary account should be business one. With
[09:31.920 --> 09:42.020]  Office 365, the defenders do have a unified logging, and it is by default enabled for
[09:42.020 --> 09:49.060]  my record collection up to 90 days. Now, from the instance I've been working more recently,
[09:49.060 --> 09:53.920]  and what we see with something like the Mandiant dwell times and Verizon DBI reports and whatnot,
[09:53.920 --> 09:58.660]  is that our dwell time is getting better, but it's still pretty long. And so that 90
[09:58.660 --> 10:02.720]  days of retention may not be enough for defenders to see what's going on, especially in the
[10:02.720 --> 10:09.880]  red team engagement. But even with a personal account, though, there's no central logging
[10:09.880 --> 10:15.960]  from what I can see on the web interface of OneDrive. So all those logs are stored locally.
[10:15.960 --> 10:20.460]  And obviously, maybe you can subpoena Microsoft or get whatever logs they have, but at least
[10:20.460 --> 10:25.340]  from the availability for IT and security professionals who are trying to investigate
[10:25.340 --> 10:30.640]  what might have happened or who accessed this, it's a bit limited. And so on the left-hand side
[10:30.640 --> 10:35.600]  there, we can see in AppData, local Microsoft OneDrive logs, we've got a couple of different
[10:35.600 --> 10:39.520]  logs that are stored locally on the endpoint. And on the right-hand side, we see the business
[10:39.520 --> 10:44.960]  unified logs. So a couple of interesting directories and folders that I've outlined here
[10:44.960 --> 10:49.940]  for you is that some of the things we can see if we've gained access to a system that is
[10:49.940 --> 10:55.500]  syncing with OneDrive is that the user profile slash OneDrive is the default data store
[10:55.500 --> 10:59.900]  of where things are going to go. If it is a Office 365 or business account, it'll be
[10:59.900 --> 11:03.920]  OneDrive dash and the company name. So we'll be able to see what company they work for as well
[11:03.920 --> 11:11.500]  and make sure it's obviously in scope. We'll then see the root directory within the logs
[11:12.560 --> 11:17.160]  directory, which is kind of strange. We'll also be able to see some metadata for local
[11:17.160 --> 11:21.800]  and cloud files. So even if the file is not synced locally, we may be able to see it
[11:21.800 --> 11:25.720]  in the sync diagnostics log. There is a big maybe there I'll talk about in a second.
[11:26.180 --> 11:32.000]  And then we're going to have a DAT and INI file. 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:49.600]  And the CID.INI file, we'll be able to see the file store locations, some sync time,
[11:49.600 --> 11:54.720]  usage details, and some other metadata there. We're going to see another file that starts
[11:54.720 --> 11:59.360]  with the CID of the user, followed by a dash and ProfileServiceResponse.txt.
[11:59.380 --> 12:05.360]  That will give us the name, email, CID, email, phone, and title, etc. of the user.
[12:05.460 --> 12:10.040]  That only is the case, though, for personal accounts. When I tried it with Office 365
[12:10.040 --> 12:15.420]  or paid versions, I did not get this file. I find that interesting because most people
[12:15.420 --> 12:20.260]  aren't going to sign in or add their title and phone number and address and stuff like that.
[12:20.280 --> 12:24.380]  I'll show you a more detailed version in a second here. And most of the time,
[12:24.380 --> 12:26.520]  you're going to see that as null, but at least you can see the email address
[12:26.520 --> 12:30.360]  that they have associated with OneDrive. And then you're going to also find
[12:32.580 --> 12:35.380]  a obfuscationStringMap.txt file, and that's going to be important to map back
[12:35.380 --> 12:38.940]  to obfuscated file names. 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:50.060]  And so you may get one of two versions. And I think I've narrowed it down,
[12:50.060 --> 12:54.320]  but I haven't had enough test cases to verify this. I'm going to call one
[12:54.320 --> 12:57.680]  the Summary SyncDiagnostics file, and the other one I'm going to call
[12:57.680 --> 13:01.840]  the Details SyncDiagnostics file. And now, what I've noticed is that
[13:01.840 --> 13:08.740]  if I install Office 365 OneDrive and I look at the SyncDiagnostics file,
[13:08.740 --> 13:14.080]  I keep getting the summary version. But if I try a personal version,
[13:14.080 --> 13:18.420]  and I've tried multiple labs and syncing it, what I've generally seen is that
[13:18.420 --> 13:22.740]  the first machine you activate OneDrive on will have the Detailed SyncDiagnostics
[13:23.480 --> 13:26.940]  log file, and then every subsequent system you sync with will have
[13:26.940 --> 13:30.080]  the summary version. So that's my theory to this point.
[13:30.080 --> 13:34.400]  Again, I need more testing for that. And I'll show you what those look like.
[13:34.400 --> 13:37.980]  So on the left-hand side here, we've got the Detailed SyncDiagnostics log,
[13:37.980 --> 13:41.500]  and you can see that there's, in the bottom part of that, there's files
[13:41.500 --> 13:44.920]  and folders that are presumably added or synced. And you can see some type
[13:44.920 --> 13:50.240]  of mount point with possibly a GUID, and then there is a backslash,
[13:50.240 --> 13:57.480]  and then a three-word string. So far, jump, sue, sue, bat, egg, and so on.
[13:57.480 --> 14:02.400]  So those are obfuscated file names, and I'll show you how to decode those
[14:02.400 --> 14:05.060]  in a second. On the right-hand side, you have the summary version
[14:05.060 --> 14:10.680]  of the SyncDiagnostics file. It's not as verbose. You have statistical data,
[14:10.680 --> 14:16.380]  sync progress, you've got last sync time, bytes downloaded, bytes uploaded,
[14:16.380 --> 14:20.500]  that kind of stuff. And so here's, again, a little bit more of the summary version
[14:20.500 --> 14:24.460]  where you could see the number of changed folders, deleted folders.
[14:24.460 --> 14:29.140]  It's really high-level information there. Now, if you happen to get that detailed
[14:29.140 --> 14:33.140]  version of the SyncDiagnostics log, what you can go ahead and do is,
[14:33.140 --> 14:36.260]  obviously, we don't know what C, bat, egg is, but you can go ahead and open up
[14:36.260 --> 14:40.300]  that obfuscation string map. And again, all of these files that I'm talking about,
[14:40.300 --> 14:45.780]  with the exception of Dropbox, they are all clear text. So these files,
[14:45.780 --> 14:49.280]  it's not something special I've had to open up. The obfuscation string map
[14:49.280 --> 14:53.960]  is just sitting in a directory that anyone can access. And when we look
[14:53.960 --> 14:59.140]  at the SyncDiagnostics, we're going to have to take that three-word string there,
[14:59.140 --> 15:03.520]  like C, bat, egg, and we're going to have to go map that to our obfuscation
[15:03.520 --> 15:07.440]  string map text file. And so there we can see that C, bat, egg essentially
[15:07.440 --> 15:10.820]  equals the desktop. So it looks like a folder was added to Sync,
[15:10.820 --> 15:14.200]  and that folder was desktop. So it's a little bit of work,
[15:14.200 --> 15:16.520]  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:29.800]  Okay, and then so the CID of the user.dat, if we open that up,
[15:29.800 --> 15:33.480]  that's going to show us the list of file names both locally and in the cloud.
[15:33.480 --> 15:36.500]  So even if it's not synced to the local file system, we can see what that user
[15:36.500 --> 15:40.280]  has access to in the cloud. And it is a little bit challenging to read this
[15:40.280 --> 15:44.000]  dat file. It's not formatted in the greatest way. So you can open it up
[15:44.000 --> 15:48.580]  in a hex editor, and you can even see searching for strings isn't the best.
[15:48.940 --> 15:53.260]  However, if you use something like strings or vstrings, that will let you
[15:53.260 --> 15:56.140]  go ahead and pull that out, and you can then obviously pipe that to find
[15:56.140 --> 15:59.000]  string or grep, and you can look for whatever you're interested in,
[15:59.000 --> 16:00.740]  or just manually parse through that.
[16:02.100 --> 16:05.580]  Okay, and in the business version, though, of the CID.dat file,
[16:05.580 --> 16:08.020]  it's a little bit different. So obviously this last one here was the personal
[16:08.020 --> 16:11.360]  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:20.080]  And so from what I've seen here, if you open up that CID.dat file,
[16:20.080 --> 16:23.440]  the files, it either is a hash or some type of GWT there.
[16:23.440 --> 16:26.440]  And so when I thought maybe it was obfuscated, and if I just open up
[16:26.440 --> 16:31.240]  that obfuscation string map text file and correlate that or cross-reference it,
[16:31.240 --> 16:37.000]  I was able to find some hits, but it was more so on the deobfuscation side,
[16:37.000 --> 16:40.740]  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:49.040]  I haven't really been able to figure out how on the business version
[16:49.540 --> 16:51.340]  to see all the file names.
[16:52.620 --> 16:56.260]  Okay, so with Microsoft OneDrive, the CID.ini file, as I mentioned,
[16:56.260 --> 17:00.560]  it's going to be a couple of different variables that you're going to see in there
[17:00.560 --> 17:02.360]  depending if it's personal or business.
[17:02.360 --> 17:07.000]  But essentially what you are going to be able to see is the CID of the user
[17:07.000 --> 17:11.680]  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:19.360]  You'll be able to see the sync activity, bytes transferred,
[17:19.360 --> 17:22.800]  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:39.400]  If you got the personal account, though, as I mentioned,
[17:39.400 --> 17:42.880]  you're going to see the display name, first name, last name, CID, email address,
[17:42.880 --> 17:45.320]  phone number, title, address, and so much more.
[17:45.500 --> 17:50.820]  However, a lot of those things like job title, when I created my sock bucket account here
[17:50.820 --> 17:56.180]  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:08.800]  And so I did not need to do that. 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:16.760]  So when I did a red shot and I took a look at what registry keys are being created here by OneDrive,
[18:16.760 --> 18:21.460]  we can see that with the business version, we have quite a few registry keys.
[18:21.460 --> 18:24.640]  With personal, it's less. 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:33.520]  And then the registry keys that the personal account had that the business did not have
[18:33.520 --> 18:38.180]  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:48.500]  So the other cool thing you're going to see if you look at the registry hive,
[18:48.500 --> 18:53.620]  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:05.820]  It may be a CID or a GUID. But essentially, when you look at that,
[19:05.820 --> 19:10.760]  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:20.500]  If you actually do a reg query on any one of those, you're going to go ahead
[19:20.500 --> 19:24.680]  and then get more details about that, such as what the actual share name is.
[19:24.680 --> 19:28.760]  And so we can see there on the amount point, it is where it's located,
[19:28.760 --> 19:33.180]  and it also tells us the name. 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:50.140]  So if someone just shares it for you and you see it in OneDrive online,
[19:50.140 --> 19:52.620]  it doesn't mean that you're going to see that registry key here created.
[19:52.620 --> 19:58.360]  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,
[19:58.360 --> 20:04.280]  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:18.620]  And once I click add, that's when that was created. And with a personal account,
[20:18.620 --> 20:22.460]  unlike the business account where you get more of that long string of random characters,
[20:22.460 --> 20:25.440]  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:55.620]  And maybe you've compromised that other user in the environment,
[20:55.620 --> 20:59.380]  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:14.960]  with the early days of cloud file storage, whether it was Google Drive or Box or Dropbox,
[21:14.960 --> 21:19.980]  getting them all mixed up here, they were... you could selectively sync files and folders,
[21:19.980 --> 21:23.880]  but it was kind of a pain if you had nested folders and you only wanted certain things synced.
[21:23.980 --> 21:28.480]  I remember I had terabytes of stuff up in Box or Dropbox, one of those solutions,
[21:28.480 --> 21:34.280]  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:46.420]  And so Microsoft, they have this new solution that allows users to view files and their names,
[21:46.420 --> 21:50.760]  but they're not actually stored on the machine. Unless you open them, they're going to pull them down.
[21:51.200 --> 21:55.720]  So in Dropbox, for example, they have Smart Sync. 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:11.640]  So in Google Drive, I keep calling Google Drive just because I'm old school,
[22:11.640 --> 22:16.580]  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:30.860]  I tested mostly the personal account just because I didn't have a G Suite account,
[22:30.860 --> 22:38.020]  but they are using SQL-like databases rather than text files and registry keys like OneDrive used.
[22:38.020 --> 22:44.420]  So within Google Drive, if you are using the business version, the Drive File Stream,
[22:44.420 --> 22:48.740]  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 --> 22:59.200]  Synced Google formatted files, what's interesting about those is that if you actually open up these files,
[22:59.200 --> 23:05.440]  like a Google Sheets document that was created on the web version, it's going to download that,
[23:05.440 --> 23:10.120]  but you can see the size there of one kilobyte. It's super small in Windows Explorer.
[23:10.120 --> 23:14.920]  And what's happening is that any Google native files, whether it's presentation, document,
[23:14.920 --> 23:19.820]  if that is a Google native file type, what's downloaded is not the actual file.
[23:19.820 --> 23:25.000]  What it actually does is kind of like a shell item, which has the URL, the doc ID, and the email address
[23:25.980 --> 23:29.600]  associated with that file. And so a couple of cool things is just looking at that,
[23:29.600 --> 23:34.240]  if you open it up in Notepad or a hex editor, you should be able to see the actual file path
[23:34.240 --> 23:40.040]  to get to that Google Drive link or that document. You'll see the ID, which isn't super relevant,
[23:40.040 --> 23:43.700]  but you also could see the email address associated with that, which is kind of cool.
[23:45.040 --> 23:48.540]  Some of the other files and folders and databases and stuff that we'll see,
[23:48.540 --> 23:54.700]  we'll be able to see in the sync-config.db, we'll see the user info, their preferences,
[23:54.700 --> 23:58.560]  initial application, install information, so when they installed Google Drive.
[23:58.560 --> 24:05.360]  In the cloud-graph.db database, we'll see metadata for local cloud and shared files and folders,
[24:05.360 --> 24:12.960]  which is cool. 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:33.180]  And then within the metadata-underscore-sqlite-underscore-db,
[24:33.180 --> 24:37.380]  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:48.800]  We can see their user email address and some of the sync time, the application version,
[24:48.800 --> 24:50.660]  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:02.480]  And within the cloud-graph database, we'll see things like the Google Drive document IDs,
[25:02.480 --> 25:05.600]  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:16.520]  Most of the stuff we're going to take a look at with timestamps, time and date stamps,
[25:16.520 --> 25:19.420]  are going to be in Unix epoch times. Just keep that in mind.
[25:19.420 --> 25:24.920]  And the ECL role column, we're going to see whether or not the user you're looking at
[25:24.920 --> 25:27.260]  is the owner of the file or it's a different user,
[25:27.260 --> 25:29.580]  so whether someone else shared it with that user or not.
[25:29.780 --> 25:34.220]  And probably the most verbose piece, and more so than any other solution we'll look at,
[25:34.220 --> 25:37.140]  is the doc-type column within this database.
[25:37.140 --> 25:41.380]  And so if you look at the cloud-graph entry table within this database,
[25:41.380 --> 25:44.280]  that's going to go ahead and give you the doc-type column.
[25:44.280 --> 25:47.720]  And there you're going to see different numeric values,
[25:47.720 --> 25:51.720]  and those are going to tell you whether the object you're looking at is a folder,
[25:51.880 --> 25:55.100]  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:06.560]  So it'll actually tell you whether or not it was a Google native presentation,
[26:06.560 --> 26:07.840]  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:15.940]  And then 6 would tell you if it's a Google Word document, essentially,
[26:15.940 --> 26:17.640]  if it's a native Google Word document.
[26:18.000 --> 26:21.840]  And then the removed column, I could not get that to fire off,
[26:21.840 --> 26:23.800]  so when I deleted things locally in the cloud,
[26:23.800 --> 26:26.060]  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:31.200]  Most of the other solutions will give you a SHA-1 hash,
[26:31.200 --> 26:34.840]  but Google gives you the MD5 hash of that file that you're looking at,
[26:34.840 --> 26:37.000]  which could be useful in certain situations.
[26:37.960 --> 26:43.420]  Here's an image of what it would look like if you open it up in DB Browser for SQLite,
[26:43.420 --> 26:45.220]  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 --> 26:55.680]  So whether they are creating files, deleting files, modifying files,
[26:55.680 --> 26:58.880]  renaming files, changing files, and so on, changing ownership,
[26:58.880 --> 27:03.880]  it is a bit messy and convoluted, so I do recommend you either grep it out
[27:03.880 --> 27:07.760]  or you put it in some type of sim where you can manipulate the data
[27:07.760 --> 27:09.400]  and get what you're looking for.
[27:09.400 --> 27:13.200]  I do recommend grepping or parsing for those keywords as action.create,
[27:13.200 --> 27:15.600]  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:23.900]  So it'll tell us whether the file was first added to Google Drive
[27:23.900 --> 27:27.800]  or if it was added locally by the user and then uploaded to Google Drive,
[27:27.800 --> 27:30.520]  whether or not it's shared with other users in the organization.
[27:31.120 --> 27:35.540]  And then the other thing you can grep for or parse for is name equals you
[27:35.540 --> 27:39.120]  and then semi-quotes around the file name you're looking for.
[27:39.120 --> 27:41.940]  So if there's a specific file name or you wanted to do a wild card
[27:41.940 --> 27:45.360]  like pass or password, you could obviously do that format as well
[27:45.360 --> 27:49.020]  and just parse out any words that have those keywords that you're looking for,
[27:49.020 --> 27:52.760]  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:01.480]  If you're taking a look at the synclog.log, I used Sumo Logic just to do a log reduce
[28:01.480 --> 28:03.240]  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:12.860]  So something was pulled from Google Drive to the local system
[28:12.860 --> 28:16.380]  and you could just kind of get a count on the different activities there.
[28:16.380 --> 28:20.800]  But again, however you want to do this to try and figure out what's going on
[28:20.800 --> 28:23.880]  or every use case can be different for what you're looking for
[28:23.880 --> 28:27.300]  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:37.900]  The thing that this database adds is that we're going to also be able to see
[28:37.900 --> 28:40.940]  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:47.880]  Here's a screenshot of what that would look like
[28:47.880 --> 28:50.620]  if you're looking at it with DB Browser for SQLite.
[28:51.160 --> 28:56.360]  Now one thing you can do is you can recreate the folder structure
[28:56.720 --> 28:59.440]  that the user would be seeing within Google Drive here.
[28:59.440 --> 29:02.620]  And so looking at some of these, you might see the doc IDs
[29:02.620 --> 29:05.980]  but not really know is this document you found within this folder
[29:05.980 --> 29:07.420]  or where is it sitting?
[29:07.780 --> 29:11.580]  And so looking at the cloud relations table within,
[29:11.580 --> 29:15.140]  I believe it's within snapshots.db and cloud underscore graph.db,
[29:15.140 --> 29:17.920]  you'll be able to then see the child and parent doc ID
[29:17.920 --> 29:20.040]  and you can recreate some of these things
[29:20.520 --> 29:23.280]  and figure out where these objects are stored.
[29:23.280 --> 29:25.460]  And so it's not super straightforward
[29:25.460 --> 29:30.100]  and I don't have a expedited process for you here just with my testing,
[29:30.100 --> 29:35.060]  but this is what you would do is if you take the cloud entries
[29:35.060 --> 29:36.860]  or whatever you're looking at there,
[29:36.860 --> 29:38.800]  but you'd see that there's a document called finance
[29:38.800 --> 29:41.120]  or a document called the Mike Wiley something.
[29:41.860 --> 29:45.800]  And you would then have to go over to the cloud relations table
[29:45.800 --> 29:48.760]  and in there we can then map those like I have on the screen
[29:49.740 --> 29:52.820]  and we can see which files are in which folders
[29:52.820 --> 29:56.520]  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:02.680]  Now I did not do a lot of testing on Dropbox
[30:02.680 --> 30:06.360]  because one, time constraint, two, I was having issues
[30:06.360 --> 30:10.180]  with how Dropbox is handling their databases.
[30:10.180 --> 30:13.400]  So kudos to Dropbox, since 2011,
[30:13.400 --> 30:17.140]  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:23.960]  So all these other solutions we have talked about
[30:23.960 --> 30:27.320]  and are going to talk about is that anyone who has access
[30:27.320 --> 30:31.080]  to the databases or log files can see all of these artifacts,
[30:31.080 --> 30:33.340]  activity and file names and whatnot,
[30:33.640 --> 30:36.840]  whereas with Dropbox that is protected.
[30:37.040 --> 30:38.600]  Now the key is stored in registry
[30:38.600 --> 30:42.640]  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:50.540]  Some of you probably have rigs way better than mine
[30:50.540 --> 30:51.840]  that can go ahead and do that,
[30:51.840 --> 30:55.660]  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:08.100]  I tried to follow some of the stuff from the DEC WinDB toolkit
[31:08.100 --> 31:11.680]  to extract those keys, but I didn't have success with that
[31:11.680 --> 31:13.580]  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:24.020]  Those contain miscellaneous temporary cache files
[31:24.020 --> 31:26.580]  that possibly were deleted by other users.
[31:26.580 --> 31:28.080]  I was able to get to some of that stuff
[31:28.080 --> 31:31.360]  without obviously having to get through encryption
[31:31.360 --> 31:33.220]  or find the decryption keys.
[31:35.640 --> 31:39.720]  The deleting on files that are local.
[31:39.720 --> 31:40.900]  So if you go ahead and delete something,
[31:40.900 --> 31:44.640]  it's going to send it to the local recycle bin on Windows machines,
[31:44.640 --> 31:46.760]  and that does not get purged,
[31:46.760 --> 31:48.580]  unless obviously the user purges it.
[31:48.580 --> 31:52.220]  Whereas on the cloud, if a user deletes something,
[31:52.220 --> 31:54.620]  it goes to the cloud, recycle bin, or trash can,
[31:54.620 --> 31:56.780]  and it's going to sit there for 30 to 120 days
[31:56.780 --> 31:59.420]  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:03.620]  So if you are looking for something,
[32:03.620 --> 32:05.520]  I do encourage you to look in the recycling bin.
[32:05.520 --> 32:06.480]  And if they haven't cleared that,
[32:06.480 --> 32:08.400]  you may be able to see purged things there.
[32:10.060 --> 32:14.320]  And so those encryption keys, as we were talking about,
[32:14.320 --> 32:16.460]  give the different locations on the screen here
[32:16.460 --> 32:17.860]  of where you can find that.
[32:17.900 --> 32:21.120]  Now, Nicholas and Florian did a talk called
[32:21.120 --> 32:27.320]  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:31.960]  If you are more interested in this,
[32:31.960 --> 32:36.600]  they were able to get into Dropbox databases.
[32:36.740 --> 32:40.620]  I did try some of the stuff that they talked about
[32:40.620 --> 32:42.240]  and some of the toolkits out there.
[32:42.240 --> 32:45.380]  There are PS1 files, so PowerShell scripts,
[32:45.380 --> 32:48.840]  as well as I believe they were Python scripts,
[32:48.840 --> 32:51.100]  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:12.580]  This is allegedly, you can go to the GitHub,
[33:12.580 --> 33:14.320]  play with it yourself, but you should be able to
[33:14.320 --> 33:15.600]  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:26.080]  Some of the files and folders and databases that were created
[33:26.080 --> 33:27.560]  when I installed Dropbox.
[33:27.560 --> 33:30.060]  We can see that there are the Dropbox cache
[33:30.060 --> 33:33.140]  and the .Dropbox files that are temporary files
[33:33.140 --> 33:34.700]  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:42.140]  Anything else though, like the FileCache.dbx,
[33:42.140 --> 33:46.600]  there are some duplicate directories as far as,
[33:46.600 --> 33:50.400]  not directories, but databases, Host.db and Host.dbx,
[33:50.880 --> 33:53.800]  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 --> 33:58.340]  And so any one of those that you see,
[33:58.340 --> 34:00.880]  oh, look, it's actually .db and it's not .dbx,
[34:00.880 --> 34:01.980]  I can get in there.
[34:01.980 --> 34:05.160]  From my testing, those were still unreadable.
[34:06.700 --> 34:09.320]  The other thing you can find is there's an info.json
[34:09.320 --> 34:12.380]  that's unencrypted and you can find the file store path,
[34:12.380 --> 34:15.000]  host ID, team setting, subscription level and type,
[34:15.000 --> 34:16.080]  how much they're paying.
[34:16.220 --> 34:19.840]  Not terribly useful, but you can get a tiny bit of information
[34:19.840 --> 34:21.600]  from that, but Dropbox really,
[34:21.600 --> 34:24.080]  I liked that they did encrypt the databases
[34:24.080 --> 34:26.940]  and didn't give you a whole lot of information
[34:26.940 --> 34:29.980]  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:36.700]  So obviously you'll find the default file store,
[34:36.700 --> 34:39.860]  but probably one of my favorites is the cache directory.
[34:39.860 --> 34:40.900]  And within the cache directory,
[34:40.900 --> 34:43.920]  you're going to find full copies of files
[34:43.920 --> 34:47.020]  that were previously opened by the user locally.
[34:47.020 --> 34:50.960]  So if they have box and they go ahead and open a file,
[34:50.960 --> 34:52.560]  whether or not that file still exists
[34:52.560 --> 34:55.120]  within the box file store,
[34:55.120 --> 34:57.960]  you still will be able to, in most cases,
[34:57.960 --> 34:58.620]  even if it's deleted,
[34:58.620 --> 35:01.620]  you'll be able to find a version of that file
[35:01.620 --> 35:03.020]  in the cache directory.
[35:03.020 --> 35:05.680]  And so I have tried in lab environments
[35:05.680 --> 35:07.360]  when I had deleted the files in box
[35:07.360 --> 35:09.920]  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:14.280]  So obviously you can go into some of the other databases
[35:14.280 --> 35:15.720]  and map that back,
[35:15.720 --> 35:19.180]  but you can easily open the file in the cache directory
[35:19.180 --> 35:20.740]  in a hex editor or text editor
[35:20.740 --> 35:23.220]  and be able to see what type of file it is
[35:23.220 --> 35:25.340]  and open it in its respective application.
[35:25.580 --> 35:26.700]  Within the logs directory,
[35:26.700 --> 35:28.640]  we'll find a bunch of different log files,
[35:28.640 --> 35:31.080]  such as the box-version.log,
[35:31.080 --> 35:32.920]  which is a detailed activity log.
[35:32.920 --> 35:36.480]  We'll find the box UI underscore some random number
[35:36.480 --> 35:38.800]  underscore the date.log.
[35:38.800 --> 35:41.440]  And that is going to be generally things associated
[35:41.440 --> 35:43.020]  with the box application.
[35:43.020 --> 35:45.940]  So when the user signs into the local application,
[35:45.940 --> 35:48.180]  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:57.060]  We also see the box underscore stream underscore number
[35:57.060 --> 35:59.020]  and then underscore date.log.
[35:59.020 --> 36:00.580]  And that's going to have file activity,
[36:00.580 --> 36:03.800]  such as files, paths, level of logging,
[36:03.800 --> 36:06.540]  free space on the volume, et cetera.
[36:06.540 --> 36:08.080]  It's got a lot of detailed information
[36:08.080 --> 36:11.780]  about files in, out, and activity around them.
[36:11.780 --> 36:14.020]  The data directory is going to have a path
[36:14.020 --> 36:15.220]  to our databases.
[36:15.220 --> 36:17.800]  We'll see databases such as the syncdb,
[36:17.800 --> 36:21.900]  streamfs.db, and metrics.db.
[36:26.200 --> 36:28.480]  So if we take a look at the box underscore streams
[36:28.480 --> 36:31.040]  underscore number underscore the date,
[36:31.040 --> 36:32.340]  and you'll find quite a few.
[36:32.340 --> 36:33.360]  In my test environment,
[36:33.360 --> 36:36.800]  I had just a handful of files and folders,
[36:36.800 --> 36:38.320]  maybe less than 30 files.
[36:38.320 --> 36:40.660]  And I was already seeing multiple versions
[36:40.660 --> 36:43.560]  of this log file with different dates on them.
[36:43.560 --> 36:45.420]  So it does seem like it rolls over pretty quickly
[36:45.420 --> 36:47.500]  and there's a lot of activity in these files.
[36:47.500 --> 36:49.940]  We'll see things with key actions,
[36:49.940 --> 36:52.120]  kind of like we saw on prior applications.
[36:52.320 --> 36:54.560]  We'll see add file, add folder,
[36:54.560 --> 36:56.360]  on delete file, on delete folder,
[36:56.360 --> 36:58.160]  on open file, on close file,
[36:58.160 --> 37:00.560]  on read file, on create file,
[37:00.560 --> 37:03.260]  on write file, and on get file info.
[37:03.260 --> 37:05.100]  These are some actions that I've identified
[37:05.100 --> 37:06.900]  just parsing through a couple of these logs
[37:06.900 --> 37:07.760]  that look interesting
[37:07.760 --> 37:10.180]  and things that may be relevant to you.
[37:10.780 --> 37:13.600]  If we take a look at the box underscore streams
[37:13.600 --> 37:17.580]  underscore number underscore date dot log,
[37:17.580 --> 37:18.380]  as you can see there,
[37:18.380 --> 37:20.600]  we'll see things like the cache path.
[37:20.600 --> 37:22.600]  So if that was modified or changed
[37:22.600 --> 37:23.480]  or anything like that,
[37:23.480 --> 37:25.960]  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:34.380]  And my favorite is that,
[37:34.380 --> 37:37.440]  as I mentioned, that box cache directory.
[37:37.440 --> 37:38.920]  And so you can see there within the directory,
[37:38.920 --> 37:40.460]  we've got these what look like GWT,
[37:40.460 --> 37:43.060]  possibly a hash, file names.
[37:43.060 --> 37:45.040]  It doesn't tell us what the originals were,
[37:45.040 --> 37:46.260]  but if you open them up,
[37:46.260 --> 37:47.480]  what you're going to see there,
[37:47.480 --> 37:48.280]  and this one was easy,
[37:48.280 --> 37:49.300]  I opened up in a text editor
[37:49.300 --> 37:51.120]  and we could see the magic byte there
[37:51.120 --> 37:52.780]  and we could tell what type of file it was,
[37:52.780 --> 37:54.680]  but it may be a file type
[37:54.680 --> 37:56.760]  that Notepad's not going to understand.
[37:56.760 --> 37:57.960]  And so if we do have a hex editor,
[37:57.960 --> 37:59.640]  opening that up and taking a look at the magic byte
[37:59.640 --> 38:01.760]  is going to be the preferred option there.
[38:01.760 --> 38:03.100]  And we can actually recreate
[38:03.100 --> 38:05.800]  or view those cache documents,
[38:05.800 --> 38:06.620]  which is great.
[38:06.620 --> 38:09.260]  The box.u, as I mentioned,
[38:09.260 --> 38:10.420]  log file there,
[38:10.420 --> 38:12.500]  you can see things like driver install,
[38:12.500 --> 38:16.160]  driver events, sign-ins, cache events,
[38:16.160 --> 38:17.180]  all kinds of activities
[38:17.180 --> 38:19.900]  around the box application itself.
[38:20.360 --> 38:23.020]  The box-version.log there,
[38:23.020 --> 38:25.220]  we can see that there are some file names,
[38:25.220 --> 38:28.340]  test.txt, when content was created,
[38:28.340 --> 38:30.660]  again, in Unix epoch time.
[38:31.220 --> 38:32.980]  And then we've got that database directory
[38:32.980 --> 38:34.820]  with a couple of those databases we've talked about
[38:34.820 --> 38:36.660]  in the sync.db database.
[38:36.660 --> 38:38.820]  We're going to have a ID of objects
[38:38.820 --> 38:40.540]  or files, folders within box.
[38:40.540 --> 38:41.660]  We're going to have a type,
[38:41.660 --> 38:42.840]  whether it's a file or folder.
[38:42.840 --> 38:44.360]  We don't get that granular level
[38:44.360 --> 38:47.340]  of document type like we saw with Google Drive,
[38:47.340 --> 38:49.220]  but at least we can tell if it's a file or folder.
[38:49.220 --> 38:50.840]  We can then see the parent ID
[38:50.840 --> 38:54.080]  so we can recreate the folder structure within box.
[38:54.240 --> 38:55.340]  The file name,
[38:55.340 --> 38:58.640]  we get the owner ID of whoever owns that file.
[38:58.640 --> 39:00.180]  So if someone else owns that file,
[39:00.180 --> 39:02.740]  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:06.680]  Unlike other applications,
[39:06.680 --> 39:07.760]  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:15.700]  I will mention with these,
[39:15.700 --> 39:18.560]  I have not tested the created date
[39:18.560 --> 39:21.800]  or updated time to verify when they're triggered,
[39:21.800 --> 39:24.160]  when they're modified and that kind of stuff.
[39:24.160 --> 39:25.160]  So that's a little bit more research
[39:25.160 --> 39:26.520]  or something you may want to take a look at
[39:26.520 --> 39:29.020]  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:35.500]  As I mentioned in the last slide,
[39:35.500 --> 39:36.840]  we've got those different fields.
[39:36.840 --> 39:38.340]  Here's an example of what you might see
[39:38.340 --> 39:41.040]  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:46.100]  I could not find documentation
[39:46.100 --> 39:50.580]  or really reverse engineer what that was doing.
[39:50.580 --> 39:53.360]  We see a cache data ID
[39:53.360 --> 39:57.340]  and that's the file name of the cached version
[39:57.340 --> 39:58.760]  that's sitting in that cache directory.
[39:58.760 --> 40:00.020]  So a few slides ago,
[40:00.020 --> 40:02.420]  we saw that cache directory and it looked like a grid
[40:02.420 --> 40:05.440]  or some hash of the file name.
[40:05.440 --> 40:06.840]  It wasn't the original file name.
[40:06.840 --> 40:08.300]  Here's where we can actually see
[40:08.300 --> 40:10.980]  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:18.340]  And then obviously the inode ID,
[40:18.340 --> 40:21.460]  we can look at that and then reverse engineer that,
[40:21.460 --> 40:24.100]  if you will, looking at the prior databases
[40:24.100 --> 40:25.920]  and find that inode ID
[40:25.920 --> 40:27.920]  and be able to see the original file name.
[40:27.920 --> 40:29.420]  And then also we'll get an age column,
[40:29.420 --> 40:32.000]  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:41.100]  So we'll take a look at that,
[40:41.100 --> 40:41.980]  or I'm sorry, not a one,
[40:41.980 --> 40:44.340]  but we'll see the epoch, Unix epoch time
[40:44.900 --> 40:46.940]  of when that file was cached locally.
[40:46.940 --> 40:48.260]  So on that far right column there,
[40:48.260 --> 40:50.580]  you'll see a few different date timestamps
[40:51.200 --> 40:52.580]  when those files were cached
[40:52.580 --> 40:53.800]  and then all the other ones there
[40:53.800 --> 40:55.800]  that were not cached locally
[40:55.800 --> 40:58.560]  on the system that we've compromised.
[41:00.120 --> 41:05.860]  Okay. And so with the streamsfs.db database,
[41:05.860 --> 41:07.160]  if we take a look at that,
[41:07.160 --> 41:09.880]  obviously there you can see in the names column
[41:10.420 --> 41:11.740]  of the syncdb,
[41:11.740 --> 41:13.740]  and that's where we can recreate the file name.
[41:13.740 --> 41:16.800]  So again, going back to the streamsfsdb,
[41:16.800 --> 41:21.040]  we can see that there's a GWT or hash there
[41:21.040 --> 41:23.780]  of A1, B4, 5, et cetera.
[41:23.780 --> 41:24.840]  That's what we would have seen
[41:24.840 --> 41:25.820]  in the cache directory.
[41:25.820 --> 41:27.600]  If we want to know the original file name,
[41:27.600 --> 41:29.880]  we go over to the inode ID column.
[41:29.880 --> 41:31.040]  We see that it's 13.
[41:31.040 --> 41:33.740]  We then open up the syncdb database
[41:33.740 --> 41:37.120]  and we can look at the inode ID for 13,
[41:37.120 --> 41:39.580]  which then go into the left-hand side there.
[41:39.580 --> 41:40.820]  We can see in the names column,
[41:40.820 --> 41:42.240]  it was called business plan.
[41:42.240 --> 41:44.160]  So that's how we can recreate those file names
[41:44.160 --> 41:46.320]  if we do find interesting cached files
[41:46.320 --> 41:48.400]  sitting in that cache directory.
[41:49.060 --> 41:50.340]  And here's just another example
[41:50.340 --> 41:52.380]  of a cached item that we can open up
[41:52.380 --> 41:53.600]  in the cache directory.
[41:53.600 --> 41:57.340]  And we can see the magic byte of PK.
[41:57.480 --> 41:58.560]  And essentially we can see
[41:58.560 --> 42:00.420]  that that is a docx document.
[42:00.420 --> 42:03.260]  So we can open up that in Microsoft Word
[42:03.260 --> 42:05.740]  or change the file extension to .docx
[42:05.740 --> 42:07.380]  and open it that way.
[42:08.080 --> 42:09.280]  And here we can see,
[42:09.280 --> 42:11.620]  obviously I didn't have Microsoft Office installed,
[42:11.620 --> 42:13.280]  but I was able to open it up in WordPad.
[42:13.280 --> 42:14.200]  And we can now see that
[42:14.200 --> 42:15.800]  that is in fact the business plan
[42:15.800 --> 42:19.200]  for startup business document that we saw.
[42:20.240 --> 42:20.920]  Okay.
[42:21.020 --> 42:23.360]  And just a couple of things on those columns
[42:23.360 --> 42:24.700]  within the stream FSDB.
[42:24.700 --> 42:25.360]  We can obviously see
[42:25.360 --> 42:26.600]  whether it's a file or folder,
[42:26.600 --> 42:28.720]  the parent's inode ID,
[42:28.720 --> 42:29.820]  the name of the file.
[42:29.820 --> 42:32.080]  We'll see multiple timestamps,
[42:32.080 --> 42:33.620]  the created at timestamp,
[42:33.620 --> 42:34.860]  the modified timestamp,
[42:34.860 --> 42:35.980]  access timestamps.
[42:35.980 --> 42:37.140]  Again, you may want to do
[42:37.220 --> 42:38.080]  a little bit of testing on this
[42:38.080 --> 42:39.520]  if that's important to you.
[42:39.540 --> 42:41.660]  I don't know exactly what events
[42:41.660 --> 42:42.580]  will trigger that,
[42:42.580 --> 42:44.420]  and I just want to warn you of that.
[42:44.540 --> 42:45.760]  We'll also see the inode ID
[42:45.760 --> 42:47.580]  of the object we're taking a look at.
[42:47.580 --> 42:49.020]  And we'll see whether or not
[42:49.020 --> 42:50.540]  the item or the object
[42:50.540 --> 42:52.360]  is marked for offline use.
[42:53.860 --> 42:57.000]  Essentially kept offline or cached.
[42:57.000 --> 42:57.640]  And then we'll also see
[42:57.640 --> 43:00.160]  folder fetch timestamp.
[43:00.160 --> 43:00.840]  So it's, again,
[43:00.840 --> 43:02.020]  Unix epoch timestamp
[43:02.020 --> 43:03.560]  or the last folder sync
[43:03.560 --> 43:05.140]  for that object.
[43:06.140 --> 43:07.400]  Let's go ahead and talk about
[43:07.400 --> 43:09.700]  Citrix share file for a second here.
[43:09.700 --> 43:11.160]  A little intro to it.
[43:11.160 --> 43:13.220]  The application to download,
[43:13.220 --> 43:14.320]  unlike all the other applications
[43:14.320 --> 43:15.360]  we've talked about,
[43:15.360 --> 43:17.440]  it's behind a signup wall.
[43:17.440 --> 43:19.760]  So you cannot just go download it
[43:19.760 --> 43:21.400]  like you would for OneDrive
[43:21.400 --> 43:24.540]  or Dropbox or anything else like that.
[43:24.540 --> 43:25.580]  You actually need to register
[43:25.920 --> 43:27.240]  for a trial of it
[43:27.240 --> 43:28.780]  using what they say
[43:28.900 --> 43:30.900]  a business or enterprise account.
[43:31.280 --> 43:32.460]  However, I was able to use
[43:32.560 --> 43:35.280]  a Gmail account for a trial request.
[43:35.280 --> 43:36.580]  Instantly got the download link
[43:36.580 --> 43:38.240]  for that and signed up.
[43:38.760 --> 43:41.660]  And then upon installing share file,
[43:41.660 --> 43:42.700]  what it looks like is it creates
[43:42.820 --> 43:45.300]  a virtual volume, FAT32,
[43:45.300 --> 43:46.340]  similar to what Google Drive
[43:46.340 --> 43:48.140]  is doing with FileStream.
[43:48.220 --> 43:50.240]  And it will automatically create
[43:50.400 --> 43:52.080]  a mounted S drive for you
[43:52.080 --> 43:53.880]  on that Windows system.
[43:54.140 --> 43:54.740]  From what I see,
[43:54.740 --> 43:56.120]  the databases are SQLite
[43:56.120 --> 43:57.400]  and they are unencrypted.
[43:57.400 --> 43:59.840]  So yet another unencrypted database.
[44:00.240 --> 44:02.420]  The key things that I've noted here
[44:02.420 --> 44:04.260]  from testing is that obviously
[44:04.260 --> 44:05.900]  the S drive or volume
[44:05.900 --> 44:08.640]  is what the default file store.
[44:08.660 --> 44:11.760]  We'll see within user profile,
[44:11.760 --> 44:14.920]  there's app data, local Citrix.
[44:14.920 --> 44:15.980]  And then within Citrix,
[44:15.980 --> 44:16.860]  you'll see a couple other
[44:16.860 --> 44:18.860]  directories and files of interest.
[44:18.860 --> 44:22.060]  Within Citrix files slash DB,
[44:22.060 --> 44:23.320]  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:29.140]  That seems to be where the most
[44:29.140 --> 44:30.520]  of the databases are stored.
[44:30.520 --> 44:32.840]  So possibly the ID directory is created
[44:32.840 --> 44:34.120]  so that if you have different
[44:34.120 --> 44:35.660]  share file accounts,
[44:35.660 --> 44:37.800]  they're stored in different directories.
[44:37.880 --> 44:39.060]  The remote DB,
[44:39.060 --> 44:40.620]  it appeared to have a list
[44:40.620 --> 44:42.580]  of all files that were remote
[44:42.580 --> 44:46.080]  and folders as well.
[44:46.080 --> 44:48.020]  And then we have a local item.db
[44:48.020 --> 44:49.620]  and that lists all the local
[44:49.620 --> 44:51.120]  files and folders.
[44:51.260 --> 44:52.760]  There's also a logs directory
[44:52.760 --> 44:53.600]  and that's where they store
[44:53.600 --> 44:55.140]  all the different log files.
[44:55.180 --> 44:58.200]  And then there's a Citrix file underscore
[44:58.200 --> 44:59.240]  and then a date.log
[44:59.560 --> 45:01.240]  and that seemed to have detailed activity
[45:01.240 --> 45:04.100]  about what's going on with share file.
[45:04.220 --> 45:05.620]  And then I also identified
[45:05.620 --> 45:07.340]  that they had part cache directory
[45:07.340 --> 45:08.400]  and that seemed to have
[45:08.400 --> 45:09.380]  all of the cache files
[45:09.380 --> 45:10.440]  that I opened up locally
[45:10.440 --> 45:11.720]  on the Windows system.
[45:12.000 --> 45:13.440]  So if we see here,
[45:13.440 --> 45:14.140]  the DB directory
[45:14.140 --> 45:16.200]  and then some ID or GWT number,
[45:16.200 --> 45:16.920]  that's where we've got
[45:16.920 --> 45:18.740]  all the different databases.
[45:18.740 --> 45:19.380]  You can see there's more
[45:19.380 --> 45:21.700]  than I mentioned on the prior slide.
[45:22.020 --> 45:22.760]  And the reason for that
[45:22.760 --> 45:23.920]  is that there are certain databases
[45:23.920 --> 45:25.080]  that were near empty
[45:25.080 --> 45:26.920]  or didn't seem to be having
[45:26.920 --> 45:28.020]  unique information,
[45:28.020 --> 45:29.580]  so I kind of left those out.
[45:30.480 --> 45:31.560]  Within the remote DB,
[45:31.560 --> 45:34.680]  we'll have a couple of different columns
[45:34.680 --> 45:35.840]  if we open that up
[45:35.840 --> 45:37.760]  in a database viewer for,
[45:37.760 --> 45:39.220]  a browser for SQLite.
[45:39.220 --> 45:41.000]  We've got folder IDs,
[45:41.000 --> 45:42.040]  parent folder IDs,
[45:42.040 --> 45:42.740]  file names,
[45:42.740 --> 45:44.800]  and global share file IDs.
[45:44.800 --> 45:46.400]  So it's assigned a unique ID.
[45:46.800 --> 45:47.880]  And we can see here
[45:47.880 --> 45:49.220]  the different files
[45:49.220 --> 45:51.260]  that I had within share file.
[45:51.460 --> 45:53.060]  We can kind of see the name.
[45:53.060 --> 45:54.260]  There's a bunch of different file names
[45:54.260 --> 45:55.140]  that I had for testing
[45:55.140 --> 45:56.500]  and then the unique ID
[45:56.500 --> 45:57.680]  to the right of that.
[45:57.980 --> 46:01.400]  The remote DB database,
[46:01.400 --> 46:03.640]  it's got a object ID
[46:03.640 --> 46:04.480]  in the database.
[46:04.480 --> 46:06.680]  It has a parent object ID.
[46:06.740 --> 46:08.220]  It has an identifier
[46:08.220 --> 46:10.480]  for the item,
[46:10.480 --> 46:10.940]  whether or not
[46:10.940 --> 46:12.360]  if it was a file or folder,
[46:12.360 --> 46:13.700]  so you can just see indications.
[46:13.700 --> 46:15.160]  Again, similar to the last example
[46:15.160 --> 46:15.740]  we looked at,
[46:15.740 --> 46:17.340]  not as detailed as Google Drive,
[46:17.340 --> 46:17.980]  but at least we can tell
[46:17.980 --> 46:19.240]  if it's a file or folder.
[46:19.240 --> 46:20.540]  We get a created date
[46:20.540 --> 46:22.220]  and Unix epoch time.
[46:22.220 --> 46:23.860]  We have a file hash
[46:23.860 --> 46:25.820]  and quite a few other columns
[46:25.820 --> 46:27.400]  that didn't seem super relevant
[46:27.400 --> 46:28.580]  for this talk.
[46:29.160 --> 46:30.480]  So here's just a sample.
[46:30.480 --> 46:31.360]  You can see there's a lot
[46:31.360 --> 46:32.820]  of different columns here.
[46:32.820 --> 46:35.040]  Quite a few were nulled out
[46:35.040 --> 46:36.320]  and other ones
[46:36.320 --> 46:37.200]  just didn't seem relevant
[46:37.200 --> 46:39.620]  for offensive security purposes.
[46:39.760 --> 46:41.220]  The local item database,
[46:41.220 --> 46:43.060]  we can see things like the key,
[46:43.060 --> 46:45.060]  there are certain columns here
[46:45.060 --> 46:47.460]  I didn't have great explanations for,
[46:47.460 --> 46:48.520]  so I left those blank.
[46:48.520 --> 46:51.040]  But again, we've got the change date,
[46:51.040 --> 46:51.880]  last access date,
[46:51.880 --> 46:52.740]  last write date,
[46:52.740 --> 46:53.920]  an ID number,
[46:53.920 --> 46:55.340]  which not sure how that differs
[46:55.340 --> 46:58.180]  from the share file unique ID
[46:58.180 --> 46:59.360]  we saw prior.
[46:59.640 --> 47:01.000]  There's a content ID,
[47:01.000 --> 47:02.060]  again, not sure how that differs
[47:02.060 --> 47:03.520]  from the key or the ID.
[47:03.700 --> 47:05.700]  And then the creation date,
[47:05.700 --> 47:06.860]  time an object was created
[47:06.860 --> 47:08.300]  in Unix epoch.
[47:08.300 --> 47:09.740]  We did get another interesting one
[47:09.740 --> 47:11.220]  is there's a URL column,
[47:11.220 --> 47:12.980]  and that gives us a cloud URL
[47:12.980 --> 47:14.800]  so it's the instance ID.
[47:14.800 --> 47:15.620]  I don't know if this changes
[47:15.620 --> 47:17.860]  for paid accounts versus trials,
[47:17.860 --> 47:20.780]  but I had some kind of trial instance ID
[47:20.780 --> 47:23.800]  .sf-api.com
[47:23.800 --> 47:26.160]  .sf-v3
[47:26.160 --> 47:27.200]  .sf-v3
[47:27.200 --> 47:27.700]  .sf-v3
[47:27.700 --> 47:27.720]  .sf-v3
[47:27.720 --> 47:28.480]  .sf-v3
[47:28.480 --> 47:28.900]  .sf-v3
[47:28.900 --> 47:29.640]  .sf-v3
[47:29.640 --> 47:30.880]  .sf-v3
[47:30.880 --> 47:33.180]  .sf-v3
[47:33.180 --> 47:41.980]  .sf-v3
[47:42.520 --> 47:44.260]  Now, I would like to do
[47:44.260 --> 47:45.300]  some further testing on that
[47:45.300 --> 47:46.660]  and figure out if we can
[47:48.060 --> 47:50.460]  use other tools aside from a browser
[47:50.460 --> 47:51.980]  to go ahead and access those files
[47:51.980 --> 47:52.800]  without authentication.
[47:53.080 --> 47:54.600]  That seems like it may be
[47:54.840 --> 47:56.540]  a security issue for share file,
[47:56.540 --> 47:58.740]  but I have not validated that yet.
[48:00.160 --> 48:01.440]  We also see a file hash
[48:01.440 --> 48:03.300]  and there's quite a few other columns
[48:03.300 --> 48:04.260]  that we see.
[48:04.280 --> 48:07.080]  Within the directory entry.db database,
[48:07.080 --> 48:09.220]  we just get very limited information,
[48:09.220 --> 48:10.420]  a parent ID of an object,
[48:10.420 --> 48:12.320]  a file name, ID of an object.
[48:13.100 --> 48:14.380]  If we go ahead and take a look
[48:14.380 --> 48:16.940]  at the Citrix files underscore date,
[48:16.940 --> 48:17.720]  and then it actually has
[48:17.720 --> 48:19.760]  the date of the file, .log,
[48:19.760 --> 48:21.860]  we'll see other actions
[48:21.860 --> 48:23.100]  that we may want to parse out
[48:23.100 --> 48:24.860]  using strings or grep
[48:24.860 --> 48:26.300]  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:33.440]  File system notifier, local,
[48:33.440 --> 48:36.480]  win, FSP, delete item,
[48:36.480 --> 48:38.420]  download, upload, read callback.
[48:38.420 --> 48:39.540]  Those are all interesting things
[48:39.540 --> 48:42.200]  that I found within those log files.
[48:42.280 --> 48:42.820]  And if we go ahead
[48:42.820 --> 48:45.440]  and take a look at that part cache file,
[48:45.440 --> 48:46.820]  it's exactly the same as we saw
[48:46.820 --> 48:48.420]  in the last example for Box,
[48:48.420 --> 48:49.960]  where in this case, though,
[48:49.960 --> 48:50.840]  it seemed to rename it
[48:50.840 --> 48:52.340]  rather than some type of GWT.
[48:53.140 --> 48:54.740]  The directory, the parent directory
[48:54.740 --> 48:56.140]  would be some type of GWT
[48:58.300 --> 48:59.460]  or hash or something
[48:59.460 --> 49:00.700]  that identified that file.
[49:00.700 --> 49:01.920]  But then within that,
[49:01.920 --> 49:04.000]  it was a single cached file.
[49:04.320 --> 49:07.300]  It was generally called 0.part.
[49:07.520 --> 49:08.560]  However, if you open that up
[49:08.560 --> 49:09.540]  and put it in with a hex editor,
[49:09.540 --> 49:10.640]  you'd see the magic byte.
[49:10.640 --> 49:12.880]  You see that it's a Word doc,
[49:12.880 --> 49:14.040]  and we could just change
[49:14.040 --> 49:16.000]  the file extension to .docx,
[49:16.000 --> 49:16.740]  and we could go ahead
[49:16.740 --> 49:18.020]  and open up that file.
[49:18.020 --> 49:19.060]  Whether or not it was deleted
[49:19.060 --> 49:19.900]  within share file,
[49:19.900 --> 49:22.440]  we now have a cached version of that.
[49:23.360 --> 49:25.360]  So in closing, one other way
[49:25.360 --> 49:25.840]  that you may be able
[49:25.840 --> 49:26.720]  to take a look at things,
[49:26.720 --> 49:28.740]  if a user is not actually,
[49:28.740 --> 49:29.600]  or they have not installed
[49:29.600 --> 49:30.440]  the application,
[49:30.440 --> 49:31.120]  but they are using
[49:31.120 --> 49:32.420]  cloud file storage solutions,
[49:32.420 --> 49:33.320]  you want to enumerate a little bit
[49:33.320 --> 49:34.600]  about what they're doing.
[49:35.880 --> 49:37.120]  I identified some things
[49:37.120 --> 49:38.440]  within Google Drive,
[49:38.440 --> 49:40.520]  where if they were using
[49:40.520 --> 49:41.720]  or viewing or editing
[49:41.720 --> 49:43.260]  Google Spreadsheets,
[49:43.260 --> 49:44.120]  you would see within
[49:45.100 --> 49:47.740]  their browser history,
[49:47.740 --> 49:48.980]  docs.google.com
[49:48.980 --> 49:50.120]  slash spreadsheets.
[49:50.120 --> 49:51.140]  If they were editing
[49:51.140 --> 49:52.200]  or viewing a presentation,
[49:52.200 --> 49:54.060]  you could see docs.google.com
[49:54.060 --> 49:55.580]  slash presentation.
[49:55.580 --> 49:56.920]  Not a ton of great information
[49:56.920 --> 49:57.860]  from that, other than
[49:57.860 --> 49:58.880]  that they are using
[49:58.880 --> 50:00.940]  Google Docs in the environment,
[50:00.940 --> 50:02.140]  and you may have to then
[50:02.820 --> 50:04.780]  attempt to gather documents
[50:04.780 --> 50:06.480]  else or a different method.
[50:06.480 --> 50:09.040]  But obviously,
[50:09.040 --> 50:10.240]  if they are using a browser
[50:10.240 --> 50:10.780]  and you have access
[50:10.780 --> 50:12.420]  to their browser,
[50:12.420 --> 50:13.840]  Google never signs you out,
[50:13.840 --> 50:14.820]  so you should be able
[50:14.820 --> 50:16.040]  to obviously just open
[50:16.160 --> 50:17.720]  a browser and access
[50:17.720 --> 50:18.520]  the documents there.
[50:18.520 --> 50:19.940]  But this is a telltale sign
[50:19.940 --> 50:20.760]  that they are using
[50:20.760 --> 50:22.160]  probably G Suite
[50:22.160 --> 50:22.960]  or Google Docs
[50:22.960 --> 50:24.260]  for the workplace.
[50:25.480 --> 50:26.740]  We can also see
[50:26.740 --> 50:27.980]  other tools,
[50:27.980 --> 50:29.520]  for example, Box,
[50:29.520 --> 50:30.460]  whether they were
[50:30.460 --> 50:31.420]  in the root directory,
[50:31.420 --> 50:32.040]  it's going to have
[50:32.860 --> 50:34.300]  app.box.com
[50:34.300 --> 50:34.960]  slash folder
[50:34.960 --> 50:35.980]  slash zero,
[50:35.980 --> 50:37.320]  and then we will see
[50:37.320 --> 50:38.200]  other indications
[50:38.200 --> 50:39.220]  of different folders,
[50:39.220 --> 50:40.320]  but at least you can see
[50:40.320 --> 50:41.220]  that they have
[50:41.220 --> 50:41.980]  signed in
[50:41.980 --> 50:42.740]  and that they were
[50:42.740 --> 50:43.580]  looking at the root
[50:43.580 --> 50:44.560]  of box.com,
[50:44.560 --> 50:45.120]  if you see that
[50:45.120 --> 50:46.460]  folder slash zero.
[50:46.800 --> 50:48.100]  With OneDrive,
[50:48.100 --> 50:48.860]  you're going to see
[50:48.860 --> 50:50.640]  onedrive.live.com
[50:50.640 --> 50:51.260]  slash
[50:51.260 --> 50:52.140]  question mark
[50:52.140 --> 50:52.920]  ID equal
[50:52.920 --> 50:53.720]  root,
[50:53.720 --> 50:54.460]  and you'll see that
[50:54.460 --> 50:55.080]  they have a personal
[50:55.080 --> 50:55.780]  account there,
[50:55.780 --> 50:56.440]  and they are looking
[50:56.440 --> 50:57.380]  in the root directory.
[50:57.380 --> 50:58.480]  You'll also see the CID
[50:58.480 --> 51:00.440]  of their personal
[51:00.440 --> 51:01.320]  OneDrive account.
[51:01.320 --> 51:02.100]  For business,
[51:02.100 --> 51:03.460]  it's a little bit different.
[51:04.200 --> 51:05.000]  They're probably going
[51:05.000 --> 51:05.300]  to be using
[51:05.300 --> 51:06.340]  SharePoint.
[51:07.260 --> 51:08.280]  If you're using
[51:08.280 --> 51:08.960]  Dropbox,
[51:08.960 --> 51:09.740]  we can see that it's
[51:09.740 --> 51:10.660]  just dropbox.com
[51:10.660 --> 51:11.360]  slash home,
[51:11.360 --> 51:12.040]  which wasn't a great
[51:12.040 --> 51:12.800]  indication of what
[51:12.800 --> 51:13.200]  they were doing
[51:13.200 --> 51:14.460]  within Dropbox.
[51:14.680 --> 51:16.460]  With viewing an
[51:16.460 --> 51:17.240]  actual document,
[51:17.240 --> 51:17.520]  though,
[51:17.520 --> 51:18.060]  showing that they
[51:18.060 --> 51:18.840]  have signed in
[51:18.840 --> 51:19.160]  and they are
[51:19.160 --> 51:19.640]  actually viewing
[51:19.640 --> 51:20.740]  content,
[51:20.740 --> 51:21.220]  you'll see
[51:21.220 --> 51:22.060]  dropbox.com
[51:22.060 --> 51:22.440]  slash
[51:23.080 --> 51:23.880]  SCL,
[51:23.880 --> 51:24.740]  and that will
[51:24.740 --> 51:25.420]  indicate that they
[51:25.420 --> 51:26.160]  have actually
[51:26.160 --> 51:26.880]  viewed documents
[51:26.880 --> 51:28.180]  within Dropbox.
[51:29.080 --> 51:30.120]  Also, if they are
[51:30.120 --> 51:31.240]  viewing the content
[51:31.240 --> 51:32.640]  of a folder,
[51:32.640 --> 51:33.280]  you're going to go
[51:33.280 --> 51:33.680]  ahead and actually
[51:33.680 --> 51:34.140]  see the folder
[51:34.140 --> 51:34.860]  name as well.
[51:34.860 --> 51:35.320]  So it's going to be
[51:35.320 --> 51:36.300]  dropbox.com
[51:36.300 --> 51:37.000]  slash home
[51:37.000 --> 51:37.700]  slash the
[51:37.700 --> 51:38.780]  folder name.
[51:38.960 --> 51:39.420]  You'll get some
[51:39.420 --> 51:40.020]  indication of the
[51:40.020 --> 51:40.660]  different folders,
[51:40.660 --> 51:40.880]  whether it's
[51:40.880 --> 51:41.540]  accounting,
[51:41.540 --> 51:42.820]  HR, etc.
[51:44.200 --> 51:45.360]  Now, one thing I did
[51:45.360 --> 51:46.160]  create for you,
[51:46.160 --> 51:46.660]  if you want to go
[51:46.660 --> 51:47.480]  ahead and shoot me
[51:47.600 --> 51:48.280]  a message on
[51:48.280 --> 51:49.200]  LinkedIn or Twitter,
[51:49.200 --> 51:49.780]  happy to share
[51:49.780 --> 51:50.720]  this with you.
[51:51.060 --> 51:51.720]  Once I created
[51:51.720 --> 51:52.740]  my lab environment
[51:52.740 --> 51:53.500]  and I wanted to
[51:53.500 --> 51:53.940]  go ahead and
[51:53.940 --> 51:56.480]  collect the metadata
[51:56.480 --> 51:57.100]  and the artifacts
[51:57.100 --> 51:57.620]  that were left
[51:57.620 --> 51:59.320]  behind, what I did
[51:59.320 --> 52:00.380]  is I created a
[52:00.380 --> 52:01.560]  CAPE target.
[52:01.560 --> 52:03.080]  And so I utilized
[52:03.080 --> 52:03.780]  CAPE, which
[52:03.780 --> 52:04.320]  generally I would
[52:04.320 --> 52:05.880]  use more in an
[52:05.880 --> 52:06.380]  incident response
[52:06.380 --> 52:07.600]  or a digital
[52:07.600 --> 52:08.540]  forensic case,
[52:08.540 --> 52:10.160]  to do a triage
[52:10.320 --> 52:11.220]  image of the
[52:11.220 --> 52:11.840]  system.
[52:11.840 --> 52:12.560]  The reason that I
[52:12.560 --> 52:12.920]  like using this
[52:12.920 --> 52:13.900]  tool is that you
[52:13.900 --> 52:15.580]  can see here,
[52:15.580 --> 52:16.860]  using this custom
[52:16.860 --> 52:18.380]  target that I
[52:18.380 --> 52:19.260]  created, it
[52:19.260 --> 52:20.040]  took 12 seconds,
[52:20.040 --> 52:20.460]  just under 12
[52:20.460 --> 52:21.200]  seconds, to go
[52:21.200 --> 52:21.720]  ahead and collect
[52:21.720 --> 52:22.240]  all that data.
[52:21.940 --> 52:22.940]  So if you want to
[52:22.240 --> 52:22.760]  play around with
[52:22.760 --> 52:24.300]  this or try and
[52:24.300 --> 52:25.100]  test this out,
[52:25.100 --> 52:25.800]  see what kind of
[52:25.800 --> 52:26.480]  cache files are
[52:26.480 --> 52:27.080]  left behind or
[52:27.080 --> 52:27.440]  that you can
[52:27.440 --> 52:29.380]  enumerate, it's
[52:29.380 --> 52:30.240]  very easy to do.
[52:30.240 --> 52:30.740]  You can obviously
[52:30.740 --> 52:31.620]  pull these yourself,
[52:31.620 --> 52:32.320]  but I found it
[52:32.320 --> 52:34.160]  useful to use a
[52:34.160 --> 52:34.960]  CAPE target so
[52:34.960 --> 52:35.940]  that I could just
[52:35.940 --> 52:36.640]  collect all of the
[52:36.640 --> 52:37.160]  different data from
[52:37.160 --> 52:38.180]  the different cloud
[52:38.180 --> 52:38.920]  providers very
[52:39.300 --> 52:39.740]  quickly.
[52:39.740 --> 52:40.360]  And so I've
[52:40.360 --> 52:41.040]  got a snippet
[52:41.040 --> 52:41.260]  there.
[52:41.260 --> 52:44.080]  I can give you
[52:44.080 --> 52:44.340]  the GitHub link
[52:44.340 --> 52:44.940]  if you go ahead
[52:44.940 --> 52:45.720]  and send me a
[52:45.720 --> 52:46.000]  message on LinkedIn
[52:50.240 --> 52:51.240]  or Twitter, as I
[52:46.000 --> 52:46.960]  mentioned.
[52:47.120 --> 52:47.940]  And that wraps
[52:47.940 --> 52:48.000]  up this session.