I'm putting it in the GitHub repo there. I've got the lab files, I've got the software you need,
and I do want to explain this because I know people are already clicking and cloning and
stuff like that. What you're going to need, there's three components to the labs that we're
going to do. One, you're going to need some software. I did it this way because with the
work from home and COVID-19 stuff, I've done at least 20 workshops in the last couple of months,
and I've started realizing that people's home internet isn't always reliable and stuff like
that. So the attempt with this, and I've had a couple people say they didn't like it, but I
think it saves a lot of us who didn't get a chance to download a 20 gig VM before the workshop,
is that rather than doing a virtual machine for you, what you have here is four pieces of software
you need that run off of Windows. So obviously you can get a VM if you want and install those,
but any Windows 10 machine should work. You need the database browser for SQLite,
Notepad++. Obviously you could use Atom or anything else, but that's the one I recommend.
You need a hex editor such as HXD hex editor, and then you do need Registry Explorer. The one
I'm using in the lab is version 1.5.2 or 20. And then there's three labs we're going to work on.
I don't know if we'll get through all of them or not, but I've got the workthroughs and actually
the answers. So if we only get through one or two of those labs, you've got everything you need.
The third component that's not on the screen here is that what I did is I had a virtual machine with
everything throughout the scenario that we're going to talk about. And with that, I then used
Cape to extract the key artifacts that we're going to look for throughout the workshop. And so rather
than getting a whole virtual machine with a couple of interesting things I wanted you to look at,
I just extracted those interesting things. So there's a zip file that's called... let's see if
I can find it on my screen here. It is evidence and then it's a dash, desktop dash, and some
random numbers dot zip. That will need a password of infected all lowercase. I recommend you not
use Windows Explorer to extract it. It generally has issues realizing that it's encrypted or has
a password. Don't worry, there is no malware. I just wanted to password protect it and I knew I'd
forget what it was called. So all my workshops I just use infected as the password. What you're
going to have in there is those key artifacts from a Windows 10 machine where an incident happened
and we'll kind of walk through that scenario and what that looked like. Okay, so I'll move on here.
My name is Michael Wiley, Director of Cybersecurity Services at Richie Mae Technology Solutions. I'm
an avid certification collector. It's just one after another. I love to learn. I've been in
the industry for a while and the more I learn, the more I realize I don't know and I need to
expand my knowledge. So some people ask why I've got certifications in such different areas. For
example, I've got some pen testing certs. Then I also have some architecture and design certifications,
your CCNAs, and then I also have a Windows Forensics certification. But I think that all
those complement my day-to-day job. And the more I learn about other fields, I realize how that can
help me in the tasks I do, even if I'm not a forensic examinator per se. I'm not for law
enforcement or anything like that. I've got my LinkedIn and Twitter information on the bottom
corner there. Please connect. That's probably the best way to get ahold of me after this.
I respond quicker, even quicker than email if you connect with me on LinkedIn. I also post a lot of
things I find relevant or interesting about the industry. Prior to my joining Richie Mae
Technology Solutions, I owned a boutique cyber security firm in Los Angeles. That's where I
really grew a lot of my security skills. Even though I'm a director now, I'm very hands-on,
and I think you'll see that a lot of my workshops and slides are quite technical in my opinion.
I get bored with paperwork, even though I have to do a lot of policy and procedure work these days.
I still like doing pen tests. I'm a recovering red teamer. I still like doing forensic
examinations. It's how I wake up in the morning, if you will. That's it about me. Let's get on to
a little bit about the company I work for. I did have my firm for a long time, and once I had a
kid, I realized I wanted to not work as many hundred-hour weeks, and I wanted to spend a
little more time with the family. So my firm merged with Richie Mae to form Richie Mae Technology
Solutions. We do a lot of cloud workflow integrations. I work with, specifically since
I'm near Hollywood, I work with a lot of the studios and the vendors that make the movies you
used to watch at AMC, and now you watch at home or on streaming platforms. So I do a lot of content
protection and workflow and stuff like that. I used to be one of 20, now I'm one of 40 worldwide
that can do security assessments on behalf of the major studios that make films. So the learning
objectives for this workshop, we're going to learn what file artifacts are available in cloud
solutions, cloud file storage solutions. We're going to see what kind of cloud file storage
user activities can be enumerated. We'll be introduced to application log capabilities,
examine the difference between providers, and so on and so forth. Now, one thing I do want to...
I want to give recognition where recognition is due. I worked in Instant the first time I started
getting into some of these cloud file storage solutions and trying to dig a little bit deeper
was I was working a case, I don't know, three years ago-ish. And it was a company where the COO
was a relative to the CEO. And that person left the company and there was suspicion that they
poached a lot of the clients. And they asked us to do a forensic examination on the hard drive and
figure out if information was sent, stolen. There was just a lot of odd behaviors about how that
person left the company. And so one of the things I found there was a cloud file storage solution,
and we were able to identify what files were uploaded, synced, things like that. And this
cloud file storage solution was not sanctioned by the company. So this was a personal account that
was installed on the Windows machine and was used to exfiltrate data, essentially. And so I got into
it in that forensic examination, and I got curious, did a little more research, and then I ended up
taking a SANS course as well. And they had a section on that that filled in a lot of the
gaps of my research that was missing. So, you know, there's a lot of people and their research
involved. So I do want to put their names on the screen and recognize them, including SANS Institute
and a lot of people that had research on sections of these tools, because there's a lot of
information throughout here, and they've helped fill in a lot of the gaps for me. So cloud file
storage overviews, you know, what exactly we're talking about when I say cloud file storage
solutions? Well, we're talking about your boxes, Dropbox, OneDrive, Amazon Drive, Google Drive,
ShareFile, iCloud, those kind of things when I talk about a cloud file storage solution.
Now, the reason they're becoming so popular is that there's this perceived benefit that you get
when you switch to one of these, reuse one of these over, let's say, a file sharing, an on-premise
file share. You get protections against disasters, and these are perceived because obviously everyone's
had their outage, but these providers can do a lot better job than system administrators, in my
opinion, from every organization to keep their data available. So when there's a pandemic, and everyone's
got to work from home, you know, overnight, essentially, you still have access to those files.
Disperse teams, they can have access to these files, rather than having a VPN in. You've got
decrease in maintenance, so system admins don't have to update the underlying operating system,
they don't have to patch Adobe, they don't have to do all that maintenance on the file share.
If anyone's ever worked with DFS, I mean, that's why cloud file storage solutions are
becoming more popular, in my opinion. They've got that high availability, they're scalable. So rather
than adding hard drives to RAID, or adding more servers to a cluster, you just literally say,
Google, here's an extra 10 bucks a month, now give me an extra terabyte. So it's very easy to
scale that. You've got ease of management. So you've just got GUIs and web interfaces, you can
provision new users through web portals, as well as single sign on, etc. It's very easy for user
management. And then we may see two different solutions that I'll kind of talk about a little
bit later. And one is that you may have a business authorized or business sanctioned cloud file
storing solution. So maybe it's an enterprise Office 365 account, and they give you OneDrive,
or you have a business version of Dropbox. But then we also run into scenarios where I often
see these different providers out there on Windows machines, or even Mac machines, where they
were not sanctioned by the company. And maybe someone thought they were doing the company a
favor because they had to move files from one machine to another. I vividly remember coming
in trying to help architect a more secure solution for a plastic surgery firm in Beverly Hills.
And the company ended up, they only had a couple people, but they were doing plastic surgery on
famous people. And they wanted to have isolated air gap networks. And I thought, great. And they
said, so this is kind of what we did. We want a better solution because we've got one computer
here for internet access. And then we have another computer over here and that has medical files.
And everyone's got two computers and they're swiveling back and forth. We call it swivel net.
So you do one job or another, so there's got to be a better way. And I was like, well,
this actually sounds fairly secure, but let me look into it. And as I dug into it, I realized,
yes, they were two different computers, but they had personal Dropbox accounts on both computers
and they were syncing the files back and forth because they needed to, obviously they downloaded
stuff from, let's say an EMR and they needed to move it into the, I don't want to say production
network, but the medical network. And there was that bridge that was gap there. And so that was
not a commercial version. That was a Gmail or Yahoo or an AOL account that the employees set up
because they thought they were making their job more efficient, but there was no control over that.
So this came from Spiceworks. I apologize. I don't have the source there. I'll try and post
that later on. But it's a Spiceworks study. You can Google it. Cloud file storage solutions,
Spiceworks, market research, and you'll find this. But I tried to extrapolate some of the
interesting things that I saw here, obviously from a couple of perspectives. One, so you know
what's more prevalent, but two, depending on which side of the fence you are on, if you're
offensive security, you can see what you're most likely to see, right? And obviously Microsoft
OneDrive, they've baked that into Windows 10 and they make it very easy for you to use OneDrive.
And so we're seeing that organizations more and more are using OneDrive solutions, right? Followed
by Google Drive. I believe that's because of G Suite and that's kind of bundled in there. And
then Dropbox is the largest independent source that you may see out there in the enterprise.
And then followed by Box has a very small market share, except for large enterprises.
We see a lot of that within different studios and post-production houses.
They've done some work with the MPA and I think that's why we see that.
And then Citrix ShareFile, not very popular, but I see a lot in the financial sector. So Richie
May really focuses on two verticals. We're in the media entertainment space and we're in the
financial space. We've got clients in all different industries, but those are really our niches.
And so I see a lot of Citrix ShareFile. I thought it was going to be more than whatever it says
there, about five to 10%. But since I see it so much, I have the research and I included it in
this workshop. So here's the two different scenarios you might run across. You may see that
on the left side there of my screen, I've got that corporate environment. Maybe they've got
CASB solution involved. There's a firewall. It's a sanctioned cloud file storage solution there.
On the right hand side there, we've got some that they may even still have that sanctioned cloud
file storage solution like OneDrive, but then the end user may use their personal G drive or
Dropbox account because they wanted to get the certain data on and off of that computer system.
And USB drives are just not as popular these days. So you may see that that bypasses CASB
solutions. A lot of the CASB solutions I've looked at are limited as far as they're not in line. And
so there's certain instances where you may install or use these cloud file storage solutions, whether
it's you install the agent or you go through the web browser and that expensive CASB solution that
you've got as your one of your layers of security may not even see that data leave or come in and
out of the network. Okay, so what kind of gems are we talking about here that we might be able to see?
If we're again, I'm trying to phrase this as two different sides. You've got this workshop I think
can go well for incident responders and forensic people. They can see what artifacts are left
behind. But I also think that as offensive security, there's also something you can gain
here and seeing that looking at this post exploitation, seeing what kind of data
might be stored and what things you can extrapolate from these agents or artifacts left behind, you
may be able to get a lot of interesting things during a pen test or red team engagement.
So many organizations are now using these tools as a file server replacement. So you might find
customer data, financials, employee data, whatever you'd see on a file share, you may see
there. I mean, all kinds of confidential stuff. The apps, if they install the application,
whether it's business sanctioned, or a personal install of the desired application, you might see
cached files. So whether that file exists still in the file system, maybe they downloaded something
and deleted it, that cached copy because it was opened up may still be there may be remnants there
that you can now pull out. So someone downloaded customer data, they realized they shouldn't have
it, they go ahead and delete it, that cache copy still there. And if you're on a pen test, you can
just go grab that cache copy and recreate all the data. You might see local files, even for cloud
files, most of the cloud file storage solutions we're going to look at, even though you don't see
the you're not going to touch the cloud files, you know, maybe they've disconnected or they
are not syncing anymore, we still can look at the databases and we can see all the files they
have access to in the cloud, even if it's not on the local file system. So we might not be
able to get those files, but now we know they're sitting there. We can get usage of different files,
we can say, wow, they're really, you know, there's a lot of work going into this one file, this
customer file, this might be something I want to look at. You may also get to be able to see traces
of deleted files. So even if they do delete it and maybe we'll see it in the cache, maybe we won't,
but even if they didn't open it up on the local file system, we may be able to get remnants of
that file. So I would kind of went over this already, it's either going to be company issued
or you might have a free account. Depending on which side you're on, again, defense or offense,
if you're on the defense and you're trying to find some of this stuff from incident response
perspective or forensics, you might look at this and say, well, if it's a free account,
we don't get access to the logs. But if it's a business account, we might actually get access to
some more advanced logging. But again, it's depending on where you sit, your background
and how you're going to use this. With the business or enterprise accounts, you know,
for Google, you've got G Suite. For Microsoft, you have Office 365. For Box, it's called Box
for Business or Box Enterprise. And then Dropbox, they call it Dropbox Pro. On the free side,
you can actually get some decent size storage there. For Google Drive, you can get free 15 gigs.
Can you imagine the amount of stuff that people can exfiltrate from your environment with 15 gigs?
With OneDrive Basic, you only get five gigs. Dropbox is the smallest, two gigs. And then
Box Starter, it's 100 gigs. The reason I don't have Citrix share file on here is that
it's only trial. There is no free version. It's an enterprise grade tool.
It's behind a paywall or trial wall that you have to go and get that. So you can use it obviously
for a while, but it's not something I'm generally going to see as an unauthorized or free version,
just because it's on the enterprise side. Okay, so let's now dive into Microsoft OneDrive.
So a little bit about it. It's baked into Windows 8 and plus. Windows 10, it's built into it. It's
almost like a virus, right? It's there. However, it's sitting there, but a lot of the artifacts
and directories, registry keys are not there until you actually authenticate. So once you
authenticate, it then becomes enabled and directories such as the AppData, local Microsoft
OneDrive directory is then created. So obviously, if that folder is not there, you can assume that
they have not been using OneDrive on that system. There's a lot of differences between the personal
and the paid version of OneDrive. So for example, the personal OneDrive log files, you're going to
see them within AppData, local Microsoft OneDrive logs. And then if it's a personal account, you'll
see personal directory. If it is a business Office 365 account, you're going to see business one
is the first account that's synced. And if you sync more accounts, you'll see business two,
business three, business four, and so on. Now, from my research, there's no logging on the
web side of it for personal accounts. However, with business, you have Office 365 unified audit
logs that provide a lot more information. And by default, those are set at 90 days.
From an incident that my team is working on currently with a massive breach, I can tell you
that 90 days is probably not long enough. So there is some stuff there, but it does get rolled over
pretty quickly. Okay. And if you look at the logging capabilities, obviously on the right-hand
side, you've got the business version there with the unified audit logs. But the personal version,
you're probably, if you want to start looking at behavior or what's happened on that endpoint,
you're going to have to look at more of the logs that are stored locally on the file system.
Okay, so this grid here is really meant just to show the different locations and what those
locations are, whether it's a file or a directory. For example, OneDrive, if you see a OneDrive
directory, it's a personal, that's where all their personal files are stored. If you see OneDrive dash
the company name, that's going to tell you two things. One, the company name, and they're using
Office 365. So you know immediately there's more logging capability, probably up to 90 days
somewhere on the cloud. Then there's other things like the root, or we've already talked about the
root log directories and how it's either personal or business one. There's an interesting file
called SyncDiagnostics.log, and that provides you with metadata for both local and cloud files. So
even if they've decided not to sync, or they have yet to sync a file from the cloud, you get access
to the name of that file in the SyncDiagnostics log, potentially, and we'll talk about that in
a second. There's a .dat file, and so the way it's going to work is if whether it's a personal
or business account, it's going to be their CID. So the customer ID number .dat, and so that's
going to differ for every system you look at. So one thing there, you get their CID number, or CID
string, and once you go into that, you're going to see a list of all the local and cloud files.
If you look at the CID.ini file, you're going to see the file store locations, the last sync time,
usage details of how they're using OneDrive, and if you look at the CID-profile-service-response.txt
file, that's going to give you only for a personal account. For business accounts, it does not exist
for my testing, but for personal accounts, it'll get you the name, email address, CID, email,
I guess I have email twice there, phone number, title, department, that kind of stuff. I think
it's interesting though, because what personal user, or if you sign up for OneDrive, it doesn't
ask for that information, like your phone number or your business title. However, that's listed
there. So I didn't even see a location when I went to OneDrive.com to go to my profile and actually
add a title and department and stuff, which is most of the time why you're going to see those
fields as null if you look at that text file. Then there's also an obfuscation string map text file.
That one's a little bit interesting, and I'll kind of show you how that works a little bit later. I
types of those sync diagnostic log files, and I haven't done extensive testing on this. However,
I do have a theory based off my limited testing. So during my testing, I had Office 365 OneDrive,
and I had... so it's a business version, right? And I didn't want to go buy 10 different versions
to test this, but I got what I'm going to call the summary version of the sync diagnostics file.
And I'll show you the two versions. Now, when I set up a free personal account, and I had two
virtual machines in my lab environment, the first virtual machine got what I'm calling the detailed
sync diagnostics file. It was much more verbose. Then I synced a second virtual machine to basically
see how that would work, and I opened up the sync diagnostic file on the second VM, and I got what
I'm calling the summary version. So my theory is that it's possibly the first machine you sync
with OneDrive, it gets the detailed version, and everyone after that, like the secondary machines
within the sync cluster, if you will, those get the detailed version. It's more of statistical data.
So let's look at the two different versions. So with the detailed sync diagnostics log file,
I can see things here like files and folders that are added. And the weird part, though,
is you'll see mount point followed by what looks like a GWID, or a CID followed by some kind of
unique character. And then it'll have a backslash, and then it'll have three words like far, jump,
sue, sea, bat, egg, car, reg, tax, rat, tad, up. So there are three words grouped together.
And when I first looked at that, I thought, what the heck is this? Obviously, there's some kind of
pattern going on, you know, three different words in the capitalization, but where is this coming
from? I don't have any files called far, jump, saw, or sue, or sea, bat, egg. That's not a folder
that I added. I'll show you how that works in a second, but we'll come back to that. On the right
hand side there, I've got the summary diagnostics file, which is the other version where you get
more of stuff like this, where you get sync progress, you get the last sync time in Unix
epoch, you get the number of files uploaded, downloaded, files, folders created, you get
basically more of summary type data. Now, going back to that detailed version, what I eventually
figured out is that those names, those three word names like sea, bat, egg, or far, jump, sue,
those things map back to the obfuscation string map. So I don't really have a knowledge of why
Microsoft did this, but I do find it interesting that if you go to the sync diagnostics,
you're not going to see the actual file names, you're seeing those obfuscated strings. It's not
terribly difficult to de-obfuscate them, it's just time consuming. And I'm sure someone's written a
parser for this, but you have to open up that string obfuscation map text file, and there you
can then map back those files. And we can see on the left side, I have sea, bat, egg, which is
equivalent to my desktop. So basically, the sync diagnostics folder is saying that my desktop was
synced. That folder was added to the sync. Okay, and here's just, again, another example,
a little bit bigger, where you could see that those different names, like joke, yak, log,
equates to my C directory. Or coy, you, quill, that's going to be myly, which is probably my
user's directory. Okay, the CID.dat file, it's a little hard to read. If you open it up in the
editor, you will kind of see the file names. However, searching, I wasn't able to do this.
And I do think it's because, obviously, those dots that are between each character, and I'm
pretty sure there's a way to search more human readable. But when I search for travel, or
itinerary, or PDF, it was not found because of those dots. So you can parse through that manually,
but a better version is probably, or a better way to do that is probably using something like
strings, or B strings. So here I use strings against that CID.dat file on the personal version.
And I was able to extract things there that are human readable, like documents, personal,
vault, pictures, camera roll. Those other things up there, as far as like E94, 23, blah, blah, blah,
explanation point, explanation point 104, I don't know what those are. And they come back to haunt
us in the business version as well. I'm not sure if those are like the CID, and then some
inode ID. I'm still doing some research into that piece. Now on the business version, though, if we
look at the CID.dat file, it's not as easy. We don't see as clear things, even if we pull it out
in strings. However, when I started looking through this, I saw what looked again like
quids, or maybe hashes there. And so I'm thinking more along the lines of their MD5 hashes. But when
I tried to search that in the string obfuscation text file, it doesn't pull things up properly.
We can see that that hash or that string is mapped somewhere, but it doesn't really tell us
what it is. It says something like 23-paged CT equals one. I don't really know what that maps
back to. So on the business versions, we didn't really get a full list of files and folders that
were added. With the CID.ini, we could see things there like the location or the URL for their OneDrive
or their Google Drive, sorry, not Google Drive, their OneDrive or their share file, I'm sorry,
share sync. And then with the last refresh time, it's in Unix Epoch, we can see the last time they
actually synced if they've got the up-to-date versions. You could see even there, I've got
all the different libraries that are shared with me, and we could see even the amount of
bytes transferred. Now that CID.dash profile service response, that one will give us, as I
mentioned, only for the personal version of Office 365, I'm sorry, personal version of OneDrive,
you've got things like the display names. We could see Michael Wiley or Mike Wiley there.
We could see the ID or the CID of my user. We can see the email address that I have registered
there. So it was a Gmail account. We could see a business phone number, which again, I don't know
why is there, and every time I've looked is null. Same thing with job title, mobile phone, office
location, that kind of stuff. I did try and compare the registry keys. So in my lab environment,
I went ahead and installed or activated OneDrive for business, and I recorded all the different
registry keys that I saw. Then I did that for the personal version, which is that middle column
there, to see which registry keys were added. You can see there's a lot less. And then I tried
to do essentially a merge of those and see which were common, so that way we can identify which
registry keys were not common. And so the only two keys in the personal version that are different
are isUpgradeAvailable and VaultShortcutPath. Otherwise, everything in the personal registry
keys, they're also going to be for the business keys. Hey, one interesting registry key that we
can find is that if we do a reg query or we use in the lab environment, I'm going to give you
a dump of the registry. So you can't obviously do a live query like I'm doing here on the screen,
but with the business version of OneDrive or Office 365, what happens is if you go
into HKeyCurrentUser, Software, Sync Engines, Providers, OneDrive. When we go into there,
you're going to see potentially multiple different keys there. And what looks like a
bunch of random characters like B736EE blah, blah, blah, plus one. And then you see C4F29 blah,
and so on and so forth. So those are actually what I think is the CID for users that have shared
folders with the user you're looking at. So you can go in here again, depending on your
perspective, if it's offensive or defensive, but you can now see that they have access to other
users files. Or if you're doing incident response or forensics, you can see that they might have
data that's mapped there that doesn't belong to them. Now, if you do another reg query below that
on one of those CIDs, so the B7 blah, blah, blah, if you go ahead and do a reg query on that string,
what's going to happen is you're going to see more keys under there, and you're going to see
the actual name, what they're calling the mount point of what's shared to them. So now I can see
there's a projects documents directory that they don't own, but someone shared with them and they
added to their OneDrive. And then obviously, you can also see the URL namespace. So you can
actually see the URL to get that. So if you are on their machine, you could possibly pop in that
URL into their browser. And if it's cached, you might be able to actually get that as well.
One thing to note with these tests, though, if someone shares something with the user,
it doesn't automatically mean you're going to see it when you do the reg query. They do have to
press add to your OneDrive in order for that to now show up in the registry. So once they press
add on the web browser version of OneDrive, if they click add this shared folder, for in this
case, I did test on a personal account, when you do the reg query, you're going to be able to see
that there. And so the difference between the business version here and the personal version
of OneDrive is that with the personal version, there is no CID of the user that shared it.
Instead, you're just going to see the name of the shared folder. If you dive into that a little
deeper with another reg query, we can actually see the CID of the user that shared it with them.
Possibly if you've compromised multiple machines with an organization, you can look at that the CID,
or if you're on the defensive side, you can take a look at that and say, well, I know Bob or Betty
or Joe or whoever shared this with that person. One other thing just to know about a lot of these
tools, I'm just going to focus here on OneDrive for a second, is that with Microsoft OneDrive
space saver, it basically allows you to not sync everything. And I remember back in the day,
Dropbox was the first cloud file storage solution that I used. And when I would sync that, I had
multiple directories and subdirectories. The challenge I had was that I couldn't get enough
space off of my machine. I had terabytes of data, and I would try and say, don't sync this folder,
but I really wanted a subfolder within that. So it was challenging to tell Dropbox which
folders to sync, which folders not to sync, get what I wanted, and also not fill up my hard drive.
So Microsoft OneDrive, their solution to that is called space saver. And what that'll do is that
it doesn't download everything. It'll essentially get you a cached copy of the file name, and you'll
see there that it's got a little cloud that's empty, and it basically means that it's cloud only.
However, you can double click on that file, and it will then be cached locally, which will have a
green check mark. Now, that'll eventually go away. I don't have documentation on how long it stays
cached locally, but if you want it to stay always locally so you could access it when you're on an
airplane or train or you don't have internet access, you could right click and say always
keep on this device. So now what we're going to do is we're going to dive into the OneDrive lab.
I do have a scenario for you that I don't think I properly put into the slides here.
So what I'm going to have you do is go to the GitHub repo, make sure you've got, again, those
four tools that you're going to use, the database browser, Notepad++, so on, so forth, and I want
those two tools installed. And then I want you to go ahead and extract the evidence-desktop-q50
blah blah blah dot zip file, which has all the artifacts for the lab. And then I want you to
start just looking at those files and seeing that it looks like basically a C drive, but it's only
a couple megs in size. What I'm going to do while you get that going, and if there's
any questions, obviously post them there on YouTube in the comments, and those will be
relayed to me so I can answer those questions. I'm going to go ahead and get the scenario
built up. I'm going to put that on the screen so you have the scenario in front of you so you could
see what we're doing. Obviously, there could be many different scenarios, but I tried to make this
fake scenario up, do it in the lab, and then I collected those artifacts for you to kind of dig
into. So what you're going to want to do is open up, and I'm going to do here on my screen,
there's three Word docs that are lab files. And the first one we're going to do here is OneDrive,
so it should be examining cloud file storage incidents dash lab dash OneDrive. So I'm going
to make this bigger on my screen for you. Expand that, zoom in, and this tells you here to navigate
to the CID dash profile services, and there's a question you're going to answer. So you basically
have to answer, what's Bob's Microsoft OneDrive CID? There's another question here, examine this
file, get the user principal name. So these are questions that you're going to go ahead and answer
and walk you through. Now, I will tell you, if you're stuck, or you've never done this before,
and you need some help, what I have is all the way at the bottom, if you keep scrolling down,
there should be a detailed walkthrough. So it'll give you the question again, exactly as you saw
it before. And it'll give you then, or the steps, the question, and then it'll also give you the
answer. And a lot of times here at the answer, what I also do is I give a screenshot. So if you
want to walk through this, and you've got less experience, and you're saying, it's all too new
to me, well, then just kind of walk through this, and you should be able to see the same exact things
on your system. So I'm going to go silent for a little while on mute here. So you have a little
bit of time to walk through these labs. When you're done, if you could start commenting and
let us know on YouTube, that way I can get an idea of when the first 10 or 15 people are done,
and we can kind of move on from there. So as I mentioned, go ahead and open this lab file,
get started on that. I'm going to put on my screen in just a second here,
the scenario, and I'll start talking about that scenario. Apologize, I didn't have that teed up
for you. Hey, Michael, a quick question in the chat around cloud file storage security.
Do you have any recommendation for, you know, scanning files for any malicious links or
malicious files themselves? Any tools, something along those lines?
Yeah, so a lot of the tools or the different solutions nowadays, they have AV built in.
I don't know a lot of details about what they are. I can tell you that they are getting really good.
I haven't done a full test where I've gotten, let's say like 1500 malware samples,
uploaded them all to see what happens. But I can tell you from experience, both
Google Drive as well as OneDrive has eaten up my malware samples that I have placed there for
different lab environments. Even when I have encrypted and password protected zip files with
malware built into them, both Google Drive and OneDrive have opened them up and used the password
infected to look inside of them. I was kind of blown away the first time I saw it. And they're
constantly improving it. They don't provide a lot of detail to that. So I used to keep a lot of my
malware in like Google Drive. And even more so, I now sometimes have PCAP files, so network traffic
that I have collected. And well, an incident happened. So let's say a user downloads a copy
of WannaCry. I captured that network traffic. Within that PCAP, there's a lot of stuff. There's
ping, there's all kinds of stuff in there. But there is an object, right? So they downloaded
that file. And if it's over a clear text protocol, all those bits and bytes and everything are
sitting in there. Nowadays, OneDrive will actually flag that. My PowerPoint slides for my incident
response workshop for Wireshark, I can no longer share my PowerPoints. And it won't even let me
download it to my computer. I actually have to go to OneDrive, confirm that I realized that they
have found a virus within a PCAP file, and then confirm that I guarantee I'm serious, I do want
to download that, and it'll let me download it. But they will not let it sync, and they will not
let me share it. So a lot of the tools, I can't speak on all of them and what their engines are
like, but I can tell you they're getting pretty good at finding stuff, even opening zip files with,
I'm guessing they're using common passwords, like infected, you know, password. And they're
trying to open up your zip files and scan those as well. If you do want a little bit more security
on top of that, and you want to know what's going on, CASB solutions will do that. I don't use CASB
a lot. However, I have used things like managed methods, we're a partner with them. And I went
through some of their documentation, and I saw that they have a back end relationship with one
of the AV vendors. And by adding CASB on top, it's scanning that. I would say if you're looking
for other things too, Microsoft is building more and more built in. So they've got their
kind of CASB solution built into Office 365. But if you want a third party, that's where it's going
to help you scan for stuff. So again, I'm going to go back to the tool I know, not saying they're
the best, but I just know managed methods. I build out a lot of regex queries for things like
social security numbers, for things that look like or password, username, stuff like that. So
it's doing antivirus scanning on top of what already Office 365 is doing. And then it's also
letting me do custom queries for things like PCI, HIPAA, and just stuff that shouldn't be stored in
OneDrive, like usernames and passwords and stuff like that. Yeah, I, you know, within my limited
experience, I have similar experiences, the cloud vendors are getting really good at defending their
own environment. It makes sense, right? I mean, they don't want to be hosting and especially if
they have that shared cloud responsibility model, they've got a lot of that on their side. And they
don't want you having things that are doing evil, or someone says, Oh, I got it from a Google Drive
link or something like that. So they have got, I'm sure some pressure to make sure that they're
keeping their customer safe and not spreading malware either. But, you know, when they did
open my zip file, I was shocked because it had a password. When they started scanning my PCAPs
and identifying malware in those, I was even more shocked, but good for them. This was the case,
I don't know why this isn't in my slides, I must have missed this. But basically, this is the
scenario that they built out for this workshop when it was the first time I did it was a four
or five hour workshop. So you're working the case of the Mike Wiley LLC case, this is going to be
more of a defensive incident response forensics type of case. But again, these concepts can be
used for both sides. So you've got Bob McLee, who is a senior manager of operations. The Mike Wiley
LLC firm is a boutique real estate investment firm in Los Angeles. Bob is a senior manager
who abruptly left the firm on 4-17-2020 in the morning. Days prior to Bob leaving,
he stepped down from all committee positions, so all board positions he was on. On Friday afternoon,
Bob updated his LinkedIn profile to co-owner of a competing real estate investment firm called
REMAX also. Within hours of Bob's departure, key clients gave contract cancellation notices.
The Mike Wiley LLC management believes that Bob may have violated his non-compete and non-solicit
clause. The Mike Wiley LLC hires a forensic incident response consulting firm to get
evidence of any violations of non-solicit, so you're part of that consulting firm. The company
did not have an approved cloud file storage solution, and some users would share files using
personal accounts for business reasons. According to HR, Bob's personal email address is
bob.maclee.re at gmail.com. So you've got that basic information about the incident,
and as you work through that, you could start seeing what kind of files. Is there anything
putting on your defender's hat, your incident response or forensics hat? Was there anything
that that user looked at, touched, synced, that kind of thing? And so I'm guiding you through in
the lab, going across that, trying to see what are some of those things that you can uncover
using some of this. And so what I did, just for a little background, is I had the web browser
opened up with all four platforms. I had OneDrive, Google Drive, Box, Dropbox, actually in Citrix,
I had five platforms. Then I also had two virtual machines. I had a primary one, which is the
information that you have, which I extracted out as the incident responder. I then also had a
second VM that you don't have access to. So there's three different possibilities. There could be
stuff on the web, there could be stuff on the VM you have, or a third-party VM, which is probably
their personal home machine. So there's possibly three different cases where files
could be added, removed, deleted, that kind of stuff. And so as we walk through, you could answer
all the questions within OneDrive, but what I try to do is have you answer certain questions
with OneDrive. Then later on, we're going to go to Dropbox, and you're going to answer some
questions through that. And then we're going to go to Google Drive, and you'll answer more questions.
So you could answer all of these questions and get all this information from one solution,
but every time I added a file, I added it to all five different solutions. Citrix, Box, Dropbox.
And so I wanted those same actions to happen across the board, but I wanted you to answer
them, again, using the different tools and know where to find them with the different solutions. So
hopefully that makes a little more sense of what we're doing and why we're doing it.
And again, if you missed it, we are looking at the OneDrive lab file where we've got the walkthroughs.
Any comments or questions on YouTube? Anyone stuck? Anyone done?
I do have a question, which is not related to the lab, but your opinion on adoption of
CASB in relation to layered protection for cloud assets?
Good question. I think it's got its purpose. I think there's different use cases. So let me
go into one where I think it's definitely useful, and then I'll go into another one where it's not.
So we work with, as I mentioned, a lot of studios and post-production houses that receive
the raw footage of the movies that are in the theater. And the challenge that we have is with
a lot of studios, they've got what's... they're very concerned about the data getting leaked,
especially after you look at Larson Studio was compromised by a hacker or hacking group,
and the contents of Orange is the New Black was held for ransom. I think it was like $97,000
or $60,000. I can't remember the exact amount. And then basically signed a contract and give
us this money in Bitcoin, and we won't release it to Pirate Bay. They ended up releasing it anyways.
So the studios have gotten very strict on that, and they've got a 96-page document called the
MPA Content Security Best Practices, and it's got everything. I mean, you should have a security
guard walking around 24-7. How do you handle their keys? You have to have an inventory of
every master key. When you're editing any content, it should be in a locked room with unique
keys to get in, like a combo lock. And that logging on that lock has to be for 12 months,
and you have to have a CCTV camera at your employees. And when your employees enter and
exit the room, you have to search them. They can't have personal items in the room. If they do,
it has to be a clear bag. It just goes on and on that most people can't really do that.
So one thing, though, is that the point of that is that the studios are very strict about,
you have to take our content, such care of our content, and how you work on our content
while it's in your environment, Mr. Post-Production House or VFX House.
Now, a lot of times, though, and I won't name which studios, but a lot of studios will still
send the raw content of Batman or whatever it is. I just used Batman as an example, but they'll
send the link for that to download the raw footage of this blockbuster movie. And they'll send that
via email with the URL and username and password to download that. Sometimes they'll also send it
over FTP, not the password, but they'll send the actual content over FTP. So I kind of feel like
that's saying to the studio, to the vendor sometimes, it's like, hey, we're going to give
you a gun, but you need to be so careful with it, you need to take a safety class, you need to
buy a lock, you need to have a safe, you need to be in a room that's got bulletproof walls and all
this stuff. But here you go, and they give you an unloaded gun without the safety on.
And so in those situations, we've recommended, even though it's not part of the MPA best practices for
our vendors, to basically, for their protection, is if you get handed a loaded gun, a CASB solution
may be able to identify those links that come in, and then track everything about it. And it'll
basically see if the... it'll almost alert. So when those links come in and possibly username and
password from the studio, in an insecure matter, it is then tracked and logged and any type of
action around that email is then alerted. Because we can't control the studio is going to hand a
loaded gun to our clients, but we can control then how we're monitoring, logging, and preventing that
from going out. So the CASB solution lets us keep track of that. And if it's ever forwarded to a
personal account or anyone outside the company, we get alerted to that. Some CASB solutions will
actually allow you to break links. So if someone puts a file up in Dropbox, or they try and share
it, it'll break that link. So in those cases of detecting and sometimes preventing, but mostly
detecting data leaving or being shared or forward and stuff like that, we absolutely recommended
that to the client. Now, other cases, we have a CPA firm that's one of our clients, and they
didn't really have a need for that. We got CASB involved originally, but we found out really,
they just didn't want anyone to share anything outside the company. There was no use case for
that. So we just disabled sharing. And in that case, we didn't really need CASB. So you kind of
have to look at what functions you're worried about. Do you want the antivirus scanning? Do you
want the regex queries? Do you want to be able to be alerted on certain events? I think a lot of it,
you can actually do now with OneDrive. If you integrate that with a tool like Sumo Logic,
you could do a lot of alerting on that. But again, every use case is different and depending on what
you're storing there. So it's a long winded answer, but there's a lot of depends, but there's
some really useful features. In other cases, a lot of businesses, I say, no, it's not right for you.
Got it. And then another question, is there any form of encryption adopted by OneDrive that
minimizes the risk of disclosure? I'm making reference to access the local files in plain
file. Got it. So not that I'm aware of. No, I think they're obviously in transit. OneDrive,
Google Drive, all that stuff is traversing over SSL TLS. And so it's essentially encrypted in
transit. And then I'm assuming it's encrypted also when it's sitting there in the cloud.
But on the local file system, no. I mean, once it's sitting there, it's sitting there.
Couple caveats though, is that a lot of those caching or those shell files, where it's only
the file name, but it's not actually downloaded. I've had issues with that. And I could see where
that could almost benefit you from security standpoint, is that if you try and copy all
the files in OneDrive onto a thumb drive or something else, it has to download each one
and then move it over. And if it doesn't have connectivity or you're signed out or anything
like that, it will error out. It won't actually copy those files over. It's really just a shell
or a shortcut that points to that file. So not really encryption, but that's, I mean,
that's one security measure. I guess it wasn't meant as a security measure, but it helps you out.
And then every solution we're going to look at today, all of them, all this local stuff,
like the caches, the logs, everything is in clear text. So you have access to all the databases
from all these tools. OneDrive doesn't use databases, it uses the registry, but Google
Drive, Box, Dropbox, Citrix ShareFile, they all use SQLite databases, and all of them are in clear
text. So you don't even need a password, you just open them up and you get access to all this stuff.
With the caveat of Dropbox, and Dropbox is the only one that actually encrypts their databases
and some other stuff at rest. So the files are not, but at least the database and the metadata,
you won't be able to get into that unless you do some further exploits.
Okay, so let me do a quick walkthrough on this, and then we'll move on to the next piece.
So the first one, it says to go ahead and navigate over to the cid-profileserviceresponse.txt file
and open it with Notepad++. So some of this, I might have an issue with my walkthrough because
my VM that I normally use for this, I haven't touched it in a while, and I forgot the password.
So I had to like last night, all of a sudden move all these artifacts over and try and get it reset
up. So if it's a little bumpy, I apologize. So you've got, if you extract that zip file
that I've got with the evidence, basically, you're going to see a folder structure of C,
essentially, if you were on the file system, you'd click on the C drive.
And then you're not going to see everything, but you're going to see the things that I extracted
with CAPE within 10 seconds. So an incident happened, you know, Bob McLee called us in,
or not Bob McLee, but the Mike Wiley LLC about Bob McLee, and said, we think there's an issue,
please, you know, figure out what happened. So what I did is I grabbed CAPE, a tool,
and I basically then, I've got a custom CAPE target that extracts all stuff related to cloud
storage solutions. I said, collect it from this hard drive, the C drive. And within 10 seconds,
it created the zip file for me, or for us. And it gives us all relevant information to these Google,
or not Google Drive, but these cloud file storage solutions. So we're going to go over to users,
Bob, for Bob McLee, we're going to go to app data, local, Microsoft. And so you can see,
this is most of the data we're going to look at today. But we're going from Microsoft,
there was no business account. So this was not a paid subscription,
this is a personal account. So immediately, we notate that for our incident,
we go into personal, and then we should see that CID dash profile service response.
So what's Bob's Microsoft OneDrive CID? Well, it's right here. Okay, so we've copied that we
now know that CID in case we see it elsewhere. The next question asks us, examine this file and
look for the principal name. So we want to double click on this. And we just make this larger for
you. Word wrap, edit, and format. Okay, and so we could see here, obviously, that they're using
OneDrive principal name, Bob McLee, so we have the right computer. We could see their CID again,
right here, we see their email address. So it was bob.mcleegmail, this matches what HR told us is
their personal email address. And then we don't see a phone number, job title, as in most cases,
we won't. Okay, the next question is, what is the device ID of the system you're investigating,
right? So we want to see, we didn't do the acquisition, all we did was given the zip file,
and we want to know, well, which system is this in case we have to go to court. Okay, so I want
to go ahead and go over to OneDrive logs, and then personal. So I'm going to close this, and go back
to OneDrive, logs, personal. And then within here, I'm going to go ahead and look for the sync
diagnostics file. So I got this one. Let me see if I have notepad++. Perfect. This is going to be a
little easier. Okay, and so within here, we can see the question was, what's the device ID? So
my device ID. So we see we copy that, and that's got a unique device ID. Get on my zoom here.
Okay, and then the next question is, how many files folders are synced? So we can just look
through here for files. 13 files were synced. Let's see if I can just make this view a little
better for you. Zoom in. There we go. That's much better. Okay, so files, there's 13 folders,
there's three, so we can see that they're not really a big user, but there might be some
interesting files and folders we want to look at. But essentially, there's 13 files that we're
looking for. Okay, and then we want to look for... next step is to navigate over to
personal, and we want to open up the obfuscation string map. So I'm going to close this or just
minimize that. Go back here. Obfuscation string map, we'll open that up as well. And so now we
can see, even if we don't know everything, we can start getting on the right hand side here,
I can see different files and folders. So I see that C drive, users, Bob, metadata, app data.
Scroll down, we can look for anything that's interesting here. Okay, we've got Bob again,
desktop, users. Okay, keep scrolling down, we could see email address, I see there's some type
of possibly PowerPoint, some mail. Okay, client. So there might be a client's folder we're looking
for. But you could just start parsing through this and start seeing different possible file
names or things that are interesting. Imagine if you see like password, or, you know, here's some
messages or messaging possibly. You know, you can just parse through that. At the very, at the
very least, even if you don't go into other things, you can start looking for interesting file names
and folders there. Okay, but then it says we are looking for, we found something that was
123, me, you, they, who, what, where, and so we want to match that up. So I can just search here
and see my searching. It's hard using a Mac and then a Windows VM, the control keys are not
matching up. There we go. Okay, so 123. And of course, it's not working. Let me see.
Go to the top again. Oh, I see. I was giving you a sample. I was wondering why the heck is the 123
not there. But really, we were trying to figure out what the C drive slash user slash Bob was
going to equate to. And so I give the example which didn't exist. But essentially, what I'm
looking for here is, if I'm trying to find my logs, I'm gonna open up a new tab. Okay, so if
I'm looking for the C drive, it would look something like this. And then users. So I look
down here for users, it's gonna be this one. Okay, and then Bob, go back here. It's gonna be
this. Copy. Basically, so if we're looking in log files, we're looking for something like this,
if we want to see things that were placed in C users, Bob's directory, right, this is
essentially the path we're gonna be looking for in the log files. Okay, then the next step here
is that we are going to navigate over to the CID.dat file. Okay, personal. And then this is
our CID.dat file, I recommend opening up with a hex editor. This one's probably expired. I'm
just going to use a different tool than you have here because I haven't installed
HXD on this one. But if we look through here on the right hand side, this should be
the ASCII. If I scroll down, we can look for things like, did I tell you exactly what to look
for? Personal vault. So we start looking for that, I'm just gonna scroll slower.
Okay, there it is, I see personal vault right here. Okay, and then we're looking for,
look at the question again, we're scrolling down looking for the next folder name that we see.
So I'm going to keep scrolling slower, scroll, scroll, scroll, nothing there. You can see why
I might want to use strings here, because this is just a little bit messy. Okay, and now I see
something else here, another folder called operations. Right, so there's another folder
called operations. And you can keep parsing this. But again, if you use strings, I didn't want to
give too many tools, but strings is going to make it a lot easier to parse that out.
Okay, the next thing I have here is we're going to open up the CID.ini file. So I'll go back over
here, CID.ini, I'll open it in notepad++. And we're going to go ahead and look for the
local file path where things are stored. So I'm looking for the library, if I scroll over to the
right here, whoops. We can see this is where things are stored for Bob. So anything that's
synced with OneDrive, it's going to be stored in this location there, C users Bob OneDrive,
which is what we'd expect. That's the default. Okay, now we want to run Registry Explorer.
And we are going to load the registry hive. So I am going to go, hopefully, I remember where I put
it. I think I put it in my downloads. Another tab here. Downloads. I did. Okay, so my installer
software, just like you do, and I want to open up Registry Explorer. And you might get an error
when you open this up. We'll see if I get it. Nope, I must have changed the settings. But if
you do get an error about Windows protecting your PC, you just click on more, and then you run
anyways, to try and bypass that. Okay, so the next step is that we want to load a registry hive.
So I'm going to click on file, load hive. Once that's loaded, I'm going to go to our evidence.
So I have extracted my evidence, I believe, in my downloads folder. And then I have my evidence
here. Click on that, click on the C drive. Within the C drive, under the users, we go to Bob. And
within Bob, we should see NTUser.dat. When I click on NTUser.dat, it's going to open up the
registry hive. But if you don't know how the registry works, it's generally going to be
dirty. Things are going to be in these log files until you reboot. That's why a lot of times when
you make registry changes, they say reboot afterwards. So these log files are the transaction
logs that are not written yet. And we want those to be written. So when we open this, we're going
to get an error probably that says, hey, it's a dirty hive. If we get that, we should. We're going
to click yes. And then it's going to say that we have to pick essentially which transaction
logs we want to replay. So I'm going to click OK. I'm going to select both the .log1 and .log2
file. I want both of these transaction logs to be replayed to the registry hive. So I click open.
Click OK.
OK. And it's going to say, where do you want this to be saved to?
I'm just going to throw it back in my evidence folder. So I'm going to go back to downloads.
C drive, users, Bob. And I'll just dump it right here. It doesn't really matter where.
And it says, great, it's been updated. And the sequence numbers match. So that's a good thing.
Do you want us to load the updated hive? Absolutely. Thank you. Yes. And it says,
do you want to load the dirty hive? No. Why would I want the dirty one? So bye-bye.
OK. And now we're able to parse this out. So now that we've loaded this up, what we want to do is
I want you to go to software, Microsoft, OneDrive, accounts, and then personal. So I'm going to expand
this. This is going to be a problem. Every time I have this in my VM, for some reason within the
VM, it gets all messed up with the font here. Let me see if there's an easier way. Or I'll
probably have to zoom in. So give me a second. And if I don't go blind before then. Microsoft.
So hard to see this. OneDrive. And accounts. Personal. OK. Now let's see if I can...
There we go. So I know it's small. For some reason, it gets all messed up in here. But
let's see if I can go even a little bigger for you. OK. So I basically just browse to the
registry location. And then... one second. Let me scroll down on the instructions so I make sure I give you the right steps.
OK. And so some of the things that you want to answer here are... oh, no.
Hang on. Sorry. Let's go back. Increase this.
Well, I may not show a bunch of these demos with the registry if this is going to happen every time.
But we can see the user email in here. So we see that it's bob.mclee.re.gmail.com.
We can look at the CID. So we can see the CID of the user down here. We can see the default file
store, which is C, Users, Bob, OneDrive. We can see the last sign-in time. Where is it?
Last sign-in time, 15.87.12.89.85. We do need to convert this from Unix Epoch time to standard time.
So you can do that by just copying and pasting this in Google or looking for a Unix Epoch converter.
And you can just sort that out and it'll give you the exact time. But almost everything we're going
to look at today, almost everything, is in Unix Epoch time. We can see the first time that the
device was synced. So if we go to client first sign-in time down here, this tells me when they
first started syncing with OneDrive. So we can get a lot of useful information just by analyzing that.
Hopefully, there's no more registry things. Let me see if there's anything else because that's
going to be a pain to do. Okay, and then we can also look at... there's one more that I'll just
show you. The registry piece here is that, aside from personal, what other directories are shared
or synced with this user that they don't own? I'm going to get to it first and then I'll zoom in
here for you. Actually, let's see if I can tell the slide here. So we want to go to Software, Sync
Engines, Providers. Okay, Software, Sync Engines, Providers, OneDrive. And so just looking here under
this OneDrive directory, we can see that Finance, Operations, and Personal. So I said what else
besides personal? So there's a Finance and Operations directory that were shared with this
user. So they don't own that. However, they have access to it. And therefore, we may be able to get
access to those files as well. And I think that wraps up that lab. There's one more question.
Clicking into the personal, another shared folder keys, registry hives, what data value do you see
in the CIDs? So I will show you that one again. So if I do click on, let's say personal, because we
know personal belongs to this user. If I go up here, try and get this down, we can see the CID
of the user that owns personal here starts with 87 and ends in B0, Bravo 0. Now, if I go click on
operations, let's go back up here and see that the CID is different. So that CID, basically, this is
a folder that is owned by someone else. Cool. That wraps up the walkthrough for that lab.
So let's move on now to Google Drive. Google Drive behaves a little bit differently. Microsoft
obviously is baked in, so they have the ability to use a lot of the registry as if it was a database.
I guess it kind of is a database, but they have access to that, right? Where some of these other
solutions have to build this to make it portable. So with Google Drive, you've got... I keep calling
it Google Drive, but the personal version is really called Backup and Sync. But I'm just going to
keep calling it Google Drive. I'm old school like that. If you're talking about the business version,
it's called Drive File Stream. It's part of the G Suite offerings. They're backed by SQLite
databases rather than just text files and registry keys like we saw with OneDrive.
So the Drive File Stream, it creates... it's a little bit different. It's similar to Citrix
share file in that it creates a virtual FAT32 volume and mounts it. So you're going to actually
have like a G Drive sitting there that looks like a mounted file or file system. Sync to Google
formatted files will create a shell. So what's interesting is that even if they're syncing,
you don't actually get the Google file locally. So if you create a Google Sheets or a Google
document within Google Drive web browser, it syncs. It's supposed to be syncing locally to
your file system. What happens is that it creates a shell file and that shell file will have,
if you open it up in a text editor or a hex editor, you'll see the URL, the document ID,
and the email address of that user. So it's kind of interesting. It's not the actual file,
it just redirects you to that. Some interesting locations and databases and files that you may
find when you are examining the system is that you've got the sync underscore config DB file.
It'll give you the user's info like their preferences, initial application sync time,
and stuff like that. The cloud underscore graph database will give you metadata for both local,
cloud, and shared files and folders with that user. The sync underscore log dot log file will
give you added, deleted, modified, renamed files for that user. The snapshot dot DB database will
give you local file metadata, so things that are just locally. And if the user is using G Suite,
the content underscore cache will give you local file caches. I think this also worked partially
with Google Drive personal version, but there was slight differences there. Also, we'll see
the metadata underscore SQLite DB. That will give offline files, cloud files, deleted files,
and other metadata. So if we dive a little deeper and look at the sync config database,
which is located inside of AppData local Google Drive, it's got a bunch of different tables,
but the one of interest is the data table. And within the data table, we're going to see
the highest application version, so we can see what version they're using, see if there's any
known vulnerabilities or exploits. With the local sync route path, you get the path of the
local file source or where those are sitting locally on their file system. We'll also get the
user's Gmail account. So here's a screenshot of what that'll look like. We pivot over into the
data table, and that's where we can see those different rows with interesting information.
The Cloud Graph database, the main table that we're interested in is the Cloud Graph
entry table. And that's going to give us stuff like every document in their Google Drive with
the unique ID, the file name or folder of the object that's synced. The last time it was modified
in Unix Epoch, I did not test on what triggers that modify time. So I do want to just warn you
if you're an incident responder or forensics, you may want to do some testing to verify that
is it a file open? Is it a edit? Is it a sync? What will trigger that modify time? I didn't go
that far into detail. The ACL role will tell you whether or not the owner, so the person you're
looking at on their system, if they own the file or if it's shared with them. We also, what's
interesting is with Google Drive is that you'll see a doc type column, and the doc type column
will give you what format the file is. And so it's a little bit limited, but it's interesting.
If you see a zero, it means that the object you're looking at is a folder or a directory
or equivalent to a directory. If you see a one, you'll see that it's a traditional file, like a
Word doc, a PDF, something like that, a zip file. If you see two through 13, those are reserved for
Google Files, but they go a little bit more detail since they own those files, obviously.
If it's three, it's a Google formatted presentation. Sorry, a two is a Google formatted
presentation. A four is a Google formatted spreadsheet. A six is a Google formatted document.
Now, there's a removed column, and I couldn't get that to trigger. So when I deleted things,
I moved to the trash, nothing really changed there. So I'm not sure what that's reserved for
or why Google has that. We also get something that's really interesting is the file hash.
So we get the file hash of the object, whether it's a Google spreadsheet, or it's a PDF,
we're going to get the MD5 hash of that object. If we open it up in the database and DB browser
for SQLite, we're going to be able to see things there, like I just talked about. Now, that doc ID
is unique across Google Drive. And so you're going to be able to identify that if you didn't have the
hash, you could find that in other databases as well. But we can even see there the different
file names of all those files that are in the Google Drive. The sync underscore log dot log
file, this one was a little bit hard to read, and we'll take a look at it. But it's, in my opinion,
a little better if you use some type of parsing tool like bash, maybe use grep or awk, or you have
a sim, you could even do a free tier of Sumo logic to parse this out. There are tons of different
actions that are interesting. Everything is started with action dot. So you could do action
dot wildcard, or if there's specific actions you were trying to narrow down to see, you know,
is this user using Google Drive? Are they deleting files? What's going on? Whatever action you're
interested in, you can parse for those, you can grep them, you can search for them, etc.
And then not only that, but you can also see the direction that things happen. So
was the action to delete, was that local? Or did they delete it within the cloud?
Did they add a new file? Was that added on the local file system? Or did they add it by going
to drive.google.com? So looking in that log file, you can actually look at the direction dot,
it'll tell you if it was initiated within the cloud or locally. You also see shared equals
and then true or false. And that tells you if it's if they're sharing enabled or not.
And then another way that I found useful for parsing for file names is I grep for name equals
you. And then you'll look, you'll be able to find all the different file names. And you could
even then grep for certain things like pass or password, or username, whatever your use case
is there. So just by for an example, I uploaded that file to Sumo Logic, and I did a log reduce
so that you could see, it gives me a count. So I'm able to start to see, well, how many files
were downloaded. And we could see there that 22 log files, or I guess entries in the log file
match that telling me that there was a download action. So something happened from the cloud,
and then it was synced locally. If we look at that snapshot.db database, that'll give us
similar things we saw before. But the added value that we see here is that whether or not
the file is shared with other users. And that's gonna be one of the new fields that we'll see
here are the columns. Something that you may have to look at for both snapshot.db and cloud
underscore graph.db is that in the cloud relations table, you'll be able to map out where things are
located. So the database doesn't give you a clear understanding of where things are positioned.
Do we have files and folders? Or do we have... what are those folders called? So you
might have to look in both those databases in the cloud relations table. And within the cloud
relations table, that gives you almost a key of where things are stored. And they're going to use
those doc IDs and the parent doc IDs. And so you could see that on the right-hand side there,
the one that starts with 1NGR blah, blah, blah, that's in the root. But then there's multiple
files there. The row 2, 3, 4, 5, those are files that are sitting within that root folder.
So this is essentially how you kind of map that back is if you're looking at, let's say,
the cloud entry table, and you want to know, well, I see there's an object called finance,
and I see a bunch of other files, but which files are sitting in the finance directory?
Well, you would open up that cloud relations table, and then you could map those out and see,
oh, okay, I get it. It's sitting in this directory. Okay, so this brings us up to a lab.
I think what I'm going to go ahead and do is dive into some of the other ones since we've got about
40 minutes left. So I'm going to keep going with the slides, and then at the very end,
I'll kind of hang around, and we can walk through some of those labs together.
So as I mentioned, Dropbox is a bit different there. Dropbox uses encrypted SQLite databases,
SQLite encrypted extension, SAE, since 2011. So very early on, they've been encrypting those
SQLite databases, so we don't have as much visibility into them. Now, the bright side,
though, is that the key for the encrypted database is stored in the registry. However,
it's encrypted with Windows Data Protection API, or DPAPI, as I'll call it. You can either brute
force the key, but good luck with that, or you can extract the DPAPI keys from memory.
I was not able to do this. I tried this in the lab a couple of times. It didn't work. However,
Francisco has a toolkit called DEC WinDBx Toolkit. I'll try and get you... hopefully,
I've got the GitHub link on the next slide or two, but there's a toolkit. There's both
Python, PowerShell, and executables that will pull that from memory. The version of Windows 10
I had in my lab environment, it would not work. So I don't know if that's because it was
a lab environment, if it was the version of Windows. I didn't get it to work. However,
there's plenty of talks out there that talk a little bit more about this. So you can go ahead
and Google Dropbox DPAPI keys, and there's some great talks to talk about this and how they did
their research. The one thing we will be able to see, though, even though the databases are
encrypted, is that we'll see the .dropbox.cache, and that contains miscellaneous temporary cache
files. So sometimes, even if there's files that are deleted by other users, we'll be able to see
those deleted files within that cache location. Also, with a lot of these different Dropbox,
is that when you delete files within the cloud, what happens is that if you're even on the web
interface or on another system, when you delete that file, it syncs that delete. But unlike the
cloud versions or the web interfaces where there's that temporary trash location that may be purged
automatically between 30 or 120 days, when you delete that on the local file system, what
generally happens is that file goes into the trash can. So often, if you go into the trash can
on the local file, you'll end up finding things that were deleted from the cloud, and those do
not get deleted automatically. It's going to take the user running CCleaner or right-clicking on
their trash can or recycle bin and emptying those. So the other piece here, and this is
the talk that I got some of this information from, was Nicholas and Florian. They did a talk called
A Critical Analysis of Dropbox Software Security. It was at hack.lu in 2012,
and they posted about it in their blog, and they talk about where these keys are located
and how they extracted this out. But these are the file locations where those keys are stored.
Okay, and I did post here, if you want to check out the dbx decryption toolkit, it did not work
for me, but if you get it working, let me know. LinkedIn, Twitter, I'd love to hear how you got it
working. So they have that toolkit located there, and you've got PS1 files, you've got Python files
that essentially will extract that out. Okay, and then I just list out here a bunch of different
directories and paths, but most of these we don't get a lot of information from because
the .dbx and the .db databases, they are encrypted. So even the ones like home.db,
where it looks like it might not be encrypted, I could not get any useful information out of
those locations. Okay, with Box. So Box is very similar to Google Drive. We have a bunch of
different files and locations, and then log files, as well as database files. The other cool thing,
probably my favorite location within Box, is that there's the appdata local box cache directory,
and that stores complete files that were opened both locally and are possibly even cached.
So we will be able to see not the file name, but we'll actually be able to recover
files, whether or not they've been deleted from Box.
Okay, we also have some log files, which give us detailed activity of both the file activity,
but then there's also a Box UI log file that tells us when the user logged in,
what kind of network connection they had, if they lost internet connectivity.
I mean, it's almost like stalking the user with the UI application. So there's a lot of
detailed information there. We also have the boxstream.log, and that's going to give activity
around metadata, paths, log locations, log files, free space on the file system, all kinds of juicy
information there. And then we also have the syncrootfolder.txt, it just tells you where the
default file store is located. And then there's a couple databases that will give you local files,
cloud files, cached files, usernames, passwords, or not passwords, email addresses, and that kind
of stuff. So if we looked at the boxstream.log, there's keywords that you might want to parse
out with grep or awk, things like add file, add folder, on delete file, on delete folder, open,
so you can get those different activities, and it'll tell you which files. So there on the screen,
we can see a file was added, the date and time, the file was called the Mike Wiley 2020 strategic
plan.rtf. Then also, we could see other things here about, you know, where things are cached,
where the database is located, mount points, stuff like that. So as I mentioned, my favorite
one is that cache directory. If you look at the cache directory, you'll see either what's a grid
or a hash for the file, but it's not the actual file name. The cool thing, though, is that if you
open up any of those files in a hex editor, you can look at the magic byte or magic bit in the
beginning, and we can see it's an rtf file. So then we could just rename that file to example.rtf,
and then we can open it up in a respective software application. The box UI, this is just a
sample of what you might see. You could see when the user logged out, when they logged back in,
hard drive space, network connectivity, all kinds of stuff built in there.
And then within that box dash, and then the date, or version number, sorry, we're going to see those
different files like test.txt, content created at, you know, different times, again, obviously,
in Unix epoch time. Okay, and then we'll see the different box databases with interesting things,
very similar to Dropbox, but this time we get SHA hashes, we can see when things were created,
they were updated, again, take that with a grain of salt, I don't know which actions trigger those
updated, if it's local, if it's cloud, if it's a combination, so you just don't want to rely on
those dates unless you're sure. So here again, you can see those different, the local IDs,
native item type, whether or not it's a file or folder, we can see the parent item ID, so we can
map out what's sitting in what location, file names, inode ID, that inode ID is going to become
important later for mapping things out to file names. Streams fs.db, there we get things like
the file name of the item that's in that cache, so we could actually now, if we open streams fs.db,
we can find out all those random file names that were sitting in that cache location,
we can actually see the true file name to see if that's relevant or not.
Okay, and then if we want to map that out, so if we want to see here, we've got the,
that, that streams fs.db, and we go in the cache file table, we don't see the file name,
but we do get to see that inode ID. So we're going to have to take that inode ID,
open up the syncdb database. And from there, we can map the inode ID and we can see, oh, okay,
so this A1, B4, blah, blah, blah, glitter hash, that is the business plan document that we want
to recreate. And if we open that up again, in a hex editor, or even a text pad, or notepad,
we can see that the, we've got the magic byte of PK, which tells us it's a .x. So we can now
rename that file business plan. .x, and we can then open it up in Microsoft Word. So I went ahead
and did that, I renamed the file, give it the proper file extension, opened it up this time
in WordPad, and we can actually see that business plan for startup business. And that file had been
deleted from, from Box. So it was no longer sitting in Box, but the cache was still sitting there.
Okay, just map out some more of those things and what those locations are for. So again,
I'm going to keep going, and then we'll come back to the lab afterwards, rather than one by one,
because I do want to make sure in the next 25 minutes or so that we do hit the rest of the
content here. And I've got about 20-ish slides left. So with Citrix ShareFile, very similar to
Google Drive and Box. The interesting thing about this is that the application, to download it,
you had to go through that paywall, or at least a trial registration for businesses only.
However, I was able to use a Gmail account and they let me just get in, but there's no free
version. Similar to Google File Stream, once you install ShareFile, it creates a virtual volume
in FAT32. It mounts as the S drive. All their databases are unencrypted in SQLite format.
So they have a list of all the remote files and folders in the remote DB.
If you want to see all the files that, and I like how they break it out,
if you want to look at all local files that are sitting there in the file system,
it's localitem.db. So you've got two different databases, whether it's local,
or they're sitting in the cloud. And again, these are things that maybe have never been synced
with the end user system, but you can find out what they have access to.
And then there's a Citrix files underscore, and then a date.log. And that gives a detailed
activity of what things have synced, what files they have access to, and stuff like that.
And then similar to Box, there's a part cache directory, where you can gain access to all
those cached files. Okay, and don't want to go too much into, again, all the different columns
and folders, but it's very similar. We get a lot of unique IDs, and we can map out where things
are sitting, what parent directory they're in, and we even have a unique ID. Similar to Box and
Google Drive, you have the hash as well, so you get that fingerprint of the file.
All right, but they actually have in these remote and the local item database,
they have a lot of columns in there, as far as permissions and stuff.
I didn't have time to map out what all those permissions meant, whether they were shared,
read, write, that kind of stuff. But you get a plethora of information, including even the file
size of the different files within Citrix ShareFile. Local items, very similar. You get the
hashes, URLs this time, though. What I thought was interesting with this one, though, is that there
was a URL within the local item database. It gave a, what I believe to be an instance ID,
.sf-api.com, and then some directories and an item ID. I tried to visit those with a browser,
and I got nothing. But I do have a feeling, though, that you're able to work with their API,
you could probably then, by using this, gain access to some of their files using that API.
Okay, and then the directory entry, this really just gives us a parent structure or a structure
of where things are. If you look at that Citrix ShareFile underscore date, and then the date.log,
these are some things that I've identified as words you might want to parse out for using grep
or awk. Upload file, file system notifier, local, win, FSP, delete item, download, upload,
read callback, those are all interesting actions when I did those in my lab environment
that triggered these log files. So similar to Box, where they had that cache directory,
if we go into the part cache, you've got these long gwids or hashes, and within those directories,
you're then going to see 0.part. Almost identical to Box, though, if you open that with a
hex editor, you're able to see it's an RTF file or a .docx file, sorry. And you just rename the
file extension. So 0.docx. And I was able to recover the entire document that way as well.
So a couple more things before we dive back into a lab or two. Some other areas that you might be
interested in, okay, well, maybe they didn't download the application. So I'm looking at a
system that I've either compromised as a offensive security professional or from defensive, I am
analyzing this Windows system and trying to figure out what they did or maybe exfiltrated data.
Well, sometimes you can use, obviously, these cloud file storing solutions without installing
the application. And so if so, there may be evidence of that happening if you go ahead and
look in their history, their browsing history. And if we look at their browser history, we can
find things like for Google Docs or Google Drive, you're going to see docs.google.com. And we could
see whether or not they were viewing or editing spreadsheets, presentations, documents, what type
of file they were editing. So we don't get insight to which file, the name of the file, but we will
be able to see if they view or edited any types of files in Google Drive. If they go to the root
of Google Drive, it's different. So if they're actually editing, it's docs.google.com. If they're
just viewing their drive and the folders in them without viewing a specific object, it's drive.google.com
slash drive slash my drive. You can also, if they browse to any subdirectories that are in their
Google Drive, so the finance or personal folder, their browsing history, you'll see drive.google.com
slash drive dash folders. And then if they want to, if they delete something and they look in
their trash, you're going to see drive.google.com slash drive slash trash, which meant they have
visited their trash can recently. Similarly, if they look at the root directory in Box, you're going to see
app.box.com slash folder and the root directory. So once they log in and they just look at all their
files and folders, it's zero. Now, if they view in personal version, though, of Box, I'm sorry, of
OneDrive, if they're in OneDrive, you're going to see onedrive.live.com slash question mark ID
equals root, which means they're in the root. And then you're also going to be able to identify
their CID. So if they say, no, it wasn't me that logged in, someone else was on my machine,
you can actually map that CID back to see how much activity they're doing on the web versus
maybe when you looked at the registry keys and you saw that they had synced OneDrive locally,
that's how you can see that that same user was logged in the browser doing stuff in OneDrive
as was installed on the application. Dropbox will just give you the root, you'll see slash home.
If they go to any other documents or view it with their emulator of like,
okay, you can view a Word doc or a PDF or something like that, you're going to see
dropbox.com slash SCL. And that tells you that they have viewed things within the web browser.
And if they want to go view or they view any contents and other folders, you're just going
to see dropbox.com slash home. And then you will see the folder name. So you actually get to see
finance operations or whatever the folder name is that they were looking at.
So the data that I gave you for the lab environment that we're going to go back to
in just a second here, I've got two slides left. The way I extracted that, and it was a new way of
doing it for this lab, since we're all virtual, and I didn't want to hand out large VMs. I used
a tool called CAPE. And I built a target, which basically says, what do you want to extract?
Now, I copied some of the stuff that was in the original target that I looked at where they had
some things for OneDrive, and I mimicked that. And I built it out for Dropbox, OneDrive, Box,
Citrix share file, and I can't remember which one I missed there, Google Drive.
But all five different ones that we've talked about today, the target that I built there,
I built that out to extract that. And it does so within about 10 seconds.
So if you run CAPE from the command line, you can see, I lied, it was 12 seconds. It's going to
pull up all the registry keys, and all those cached files, and anything else that is identified
with one of those cloud file storage solutions. Now, if they have tons of data, it might be a
little bit longer. But the point is, within 12 seconds, whether I'm on an offensive or defensive
engagement, I'm able to exfiltrate, or not exfiltrate, but grab all of that useful information
that shows me any type of evidence that they are using those files, and possibly even the
cached files that I can recreate. So that brings us into the lab. I think the second lab that we
skipped over is going to go ahead and be Google Drive. If you've got to take off, I know it's,
you know, I'm here in Los Angeles, it's already 5pm. But if you're on the East Coast,
it's probably a bit later, or maybe somewhere else around the world.
I encourage you to connect with me on Twitter, and LinkedIn, that's the best way to get a hold of me,
and chat in the future. For those of you who are staying around for the next 20 minutes or so,
we're going to go ahead, I'll give you about 10 minutes to try the Google Drive lab. And after
you try the Google Drive lab, then I'll do a quick walkthrough. So on my screen here, I'm just going
to pull up the ones you see which one we're looking at. So it's going to be examining cloud
file storage incidents lab, Google Drive, again, just like the other one, you've got the lab
instructions. And then if you scroll all the way down, you'll be able to see the detailed walkthrough.
Okay, I'll go ahead and do the walkthrough here. So the first instruction says to run
DB browser for SQLite. And it's located, in this case, it says C program, DB browser SQLite,
but we've got to install that. So let me go down to my installs and get that going.
Okay, and then once this loads here and finishes up, we're going to browse to Google Drive, or it's
in AppData, local Google Drive, and then user default. And we're looking for the sync config
database. Okay, so I'm going to just run DB browser for SQLite. Pin this. Perfect. Okay, so we're
open database. I'm going to go to my downloads, evidence, and C drive, users. Oops, sorry.
Windows, system 32. No, I am all messed up here. I apologize. C, users, Bob, AppData, local,
Google, Drive, user defaults. And then within here, that's where I'm looking for the sync config.
So I've got that database, I open it up and expand this out a little bit.
Okay, and then we go down the instructions here, we're going to look for, click on the browse
data tab. So if we click over here, browse data, we get a better view of everything that's going on.
Expand this out a little bit. Okay. And so the first question is, what is the data value for
the following? So we're looking for the highest application version, local sync route path and
user email. So we can see here, this is the version of Google Drive that was installed
on the machine that we're looking at. So again, we can look for vulnerabilities, we can
match it up to the system, whatever the use case is. And then local sync route path.
Oops, I messed that up. Local sync route path, here we see it is cusers, Bob, Google Drive.
And then for email, we see it's bob.mckley.re.gmail.com. It's the same one that the HR had in
their file. Step two is we're going to browse to Cloud Graph. So I'm going to go open a new database
and within Drive, it's user defaults, Cloud Graph, cloudgraph.db.
And I don't want to save changes.
Now on this one, I'm going to have to change the table here. And so it tells me to go to the
Cloud Graph entry table. So click on that one. And then from here, we want to know what's the
file name for doc type six. So I'm looking for doc type six here, I see one that's this one.
So it's a remember from, what was it, three to 12 or 13. Those are Google formatted documents.
And I'm gonna expand this file name to see what this file was called.
Ways to tell your boss you're leaving. That sounds suspicious, something you might want
to look into a little bit more. Okay, and then let me look down for
here. And then we want to look at what type that was. Obviously, we can go back to the slides and
see that that was a Google formatted doc. And we want to look at the modified date for a file
of where the file type was six. So I can scroll over modified date, right this date, though,
we're gonna want to copy this. And let me go ahead and do this. I'm just going to open up Google here.
And I convert this, we could see the exact time. I'm going to paste in the time that we got.
And it's going to tell us both are my local time as well as UTC or GMT. If we're looking at GMT,
it was Friday, April 17 2020 601 25am. And that's something that we're going to want to go ahead and
look at. And so even if we look at local time, though, for me, it was at 1101pm. So if this is
a work machine, why are they the file name was tell your how to tell your boss you're leaving.
And I believe this was the night before I believe on the 17th the morning of
Bob McClee put in notice. So at 11pm was looking for ways to find bosses leaving.
Okay, then we've got on the scroll down my tutorials.
Catch up. Okay. And then after we converted that our next step or question is further examine the
file. examination of file name column and database uncovers additional documents of interest,
for example, Doc ID one, or one MP, blah, blah, blah. One was the document last modified. So
I'm looking over here, there's one that we want to look at one MP. So I'm looking here one and
this one here. And it says resignation letter ready dot
RTF. And so we want to look here at the modified time and copy this again.
I'm going to go back over to Google.
pop this in
convert and it looks like Friday, April 17 617 am. So oops, something scrolling way down.
So it looks like the morning of right putting resignation around maybe eight or 9am when
everyone came in the morning of on the work machine, this this document was modified.
Or at least Yeah, last modified. So we don't know what it originally had. But obviously,
it says it's ready to go. And we saw the resignation letter come in on the 17th in the morning.
Go back.
Next step is to what is the hash for the file file name client list. So if we look for the
file here called client list in row 12 can scroll over and now we get the file hash here.
And this might be important because we may see changes along the way. Maybe we look at the
cached version and it's different than this. And maybe we want to verify this, this is the client
list that he stole or that we have in our file server. So we might want to copy that hash down.
Okay, next piece is that we are going to open up the sync log.
So I'll minimize this, we'll go over here. And go to my downloads, go to the evidence we've
collected, click in there, see, and users, Bob, app data, local, Google, drive, and then user
default. And then within here, we should see the we're looking for sync log. This one open up and
expand that a little bigger for you. And within here, again, ideally, you do something like
Sumo logic or some other tool to parse this out. We want to look at where did the file originate
from. And, and we're looking for specific things like resignation letter. So I want to see when
things were synced and changed here. So let me do a search and find and I'm going to search for
resignation letter. Okay, and then here, we see that close this out.
Right, so we get the date and the time all the way on the far left there was the 16 2235, at least
local time. Over here, we see receive change directions upload. So the user on this system
that the work machine, the file was changed. And then this, the changes were synced or uploaded to
the cloud and matches the file name. And look at this resignation draft, we saw resignation
letter ready. So this might have been changed around that time. Originally, it was in draft
format, and the user changed that. And sometimes we also get hashes here as well. Okay, but it was
a local system. So it was the direction was upload, they made that change locally, it got synced up.
Next question is, we want to find all for all instances of this. And again,
some other parsing tools better. But if I go here to search, and I type find again,
and I do find all in open document, this is going to give us a list. And I don't know how to make
this bigger for you. But we can see here all the different times that resignation letter was
was in here. But basically, what I would do in a much better way with some other tools,
I'm looking here for the name resignation letter draft, draft, draft,
draft, and I want to kind of find down here where it's changed from draft. So I see ready down here,
I don't want to spend all the time doing this. But I'm going to look for the line item where it
says draft, and then the next one says ready. And that's going to tell us when that change was made,
where they renamed the file, and now it's ready. Okay, and then
next step, we go back to SQL Lite. And we look for an inode ID for an office lease. I know we're
pretty much out of time there. So I know all the other steps are in the detailed walkthrough. If
you want any of that, I did want to give a couple of minutes for questions before I've got to leave
and be respectful of everyone's time. So again, there's a couple more steps to that lab, but you
can look through those we didn't get to the box lab. But you can absolutely go through those and
hit me up on LinkedIn if you have any questions around that. So I'm going to switch back to my
slides and see one more time. If there's any questions, I also want to give a big shout out
and thanks to all the people at the cloud village, the ones that you heard vocally, but then there's
tons of people on the back end who have made this possible and obviously for free. So big
thanks to them and thank you for having me here.