Man In The Cloud Attack

[Music] opportunity to associate with a lot of like-minded individuals so uh thanks for being here. So, a little bit about me, um whenever I get asked, you know, when did you get involved in security, I always like to uh thank WinNuke95 for that. Back in those good old days, for those that can remember that uh time period, it was a super simple. I could jump on ICQ, pick up IP addresses, and have a great Friday night just watching people drop off of that session so uh that's that's how I like to say I got started. Um attended UVU, a wonderful place as well. And then I've spent jumped around a number of different places, touched a lot of different

places in security. Um now I'm a security engineer with Imperva, and uh I've done a number of things there. Uh enjoying what we do there. So, uh what we're going to talk about today is a type of attack um that we've seen a few places in the wild, not not a whole lot. I think we're going to increase increasingly see this type of type of an attack, and uh we're going to talk a little bit about today some of the challenges, kind of why we're going to see it. I'm kind of looking uh for some validation here from you guys um around uh just the overall cloud adoption and how things are progressing in your

industries. I uh you know, I know know I know what I see, but I want to see what you know what you guys see as well. Um and in that regard, um from a cloud adoption trends, we're seeing more and more leave the traditional data center. Um I think we can see that here. Um I'm sure you guys uh are experiencing that. I've noticed every kind of every company, every industry has a different level of um comfortability with the cloud, moving their data, and moving their services to um either an infrastructure as a service AWS uh Azure, or some other solution, private maybe. Um but more and more we're seeing those solutions pick up and

and and get out of that traditional boundaries where we've seen. I think that's kind of an old story. Um from the SaaS perspective, we're seeing um obviously SaaS vendors uh solutions and companies spring up overnight, it seems like. Uh like one of the couple things here that I've found, I'm going to focus on what's referred to as uh EFSS, enterprise files uh sharing uh services. Uh so, this is your Box, Dropbox, Google OneDrive. Um we're going to be focusing on those a lot. One thing I thought was interesting was some of the numbers around this. Um and I think these are probably even a little bit low. Um I came up with um you know, one thing that we do is

help categorize some of these, and we had up to about 2,300 um SaaS applications that allow customers to store files in the cloud. Uh where that can be Salesforce. It just seems like everything allows you to hold on to some piece of your data um in the cloud. And so, along with that, the big the big four really is what's highlighted here in this bottom pie chart. Uh we see Google Drive, Dropbox, Box, and OneDrive being the key leaders. Um Gartner uh came out with a magic quadrant last year. Still waiting for one this year. And we can see where the where those four sit as far as their prevalence in the market space. Um I personally haven't come across

Citrix uh or Ignite. Does anybody out there use one of those for file sharing? We got one hand. That actually probably matches up with our percentages on that previous slide, so that makes me feel good. Um but obviously the other four um are everywhere. I come across them on a daily basis with the customers that I work with. Um and it seems like uh everybody's grateful. They they they use these first, and then they think about security later and how that's going to be addressed. So, what are you know, what's the attack vector space that we look at whenever customers use these? Um you know, where is the data going? Uh what device is it going to be on?

But more importantly, um you know, we see account breaches, so usernames, passwords all the time. Um if somebody gets a hold of that right stuff, they could log into OneDrive on the web, something like that. Um and then all of a sudden they have access to those files. So, there's a couple mitigations that we'll talk about here at toward the end of this uh about how we can kind of limit some of those attack vectors. But mostly you're looking at account takeovers. Um so, and traditionally it has been using a password. We're going to talk about a different way that that can happen uh without needing to know that password or or the username. Uh it's mostly an

attack based strictly on those thick clients. Um and I I think it's going to be pretty interesting here. Otherwise, outside of that, there's the standard data leakage, um data exfiltration, and then how do you manage that from a BYOD perspective uh when you have um lots of personal devices that these that this data can sync to. Is that going to be allowed in your organization? Uh what steps are you taking there to protect that? So, the motivation for this kind of attack, really we need to look at how current botnets are leveraged. Um and kind of some of the pain points that an attacker might have in setting up a botnet to target something like this.

So, the infection on this is usually a botnet you need to find a zero-day exploit to compromise the machine. After you found that, you need to stick some type of malicious code in there. Uh you want it to persist. You don't want to lose control of that machine. Um you have to have established some type of communication that's going to sneak through an IDS or an IPS or some firewall to exfiltrate it. And then you got to have a command and control infrastructure that you've already set up and secured and then made sure nobody's going to get it and take it down and so forth. Um so, those are a lot of steps, and then you look in

you know, we're not in botnet 1.0 anymore. People are are moving forward, and they're looking at some of these points. So, what what else could they do then? You know, in order to stop all this, there uh is a dime a dozen vendors that can pinpoint each part of this basically infection chain to prevent a botnet from from getting in being successful and and occurring on your systems. Um I've worked with a number of customers, and then we show up, and all we have to do is deploy a couple log monitoring solutions and categorize this kind of stuff, and very easily we can pinpoint, yep, that machine's been compromised. We take it down, and it's

it's out of there. It's pretty easy to kind of detect some of these machines now uh with the solutions that are out there. Um so, what then does what then is an attacker looking for? So, the holy grail here, the the the most awesome thing if I want to start up a botnet, is going to be I don't need to come up with a zero-day. Right? I don't want to have to write some complex exploit. Just give me a a quick way I can compromise somebody's machine. I don't want to install anything, any malicious software. I I want that to be done for me, or another way that I can get to what I want to get to without having to come up

with a compromise. Um I don't want to have to control command and control anything. Just give it to me wherever I'm at. I'm not going to want to go and and buy server space in some top secret, you know privacy-controlled uh company out of Sweden or something. Just just give it to me. And I don't want to have to use proprietary or some other type of protocol. I want this to go over standard communication that we can't be blocked. If you turn me off, you turn off the actual service that I'm leveraging. Okay? And so, how that can be done is existing software, obviously standard communication. We want to rely on what's out there, leverage what's already being used.

Um and then not have to have command and control servers to collect this. And that's where those whole EFSS cloud file synchronization services uh come in and provide us some of that capability. So, why is that? Let's think about what um you know, how this already works, right? So, where is OneDrive, Google Drive? Where does this stuff live? It already lives out in the firewall. It's outside in the cloud. That's my command and control server right there. Okay? It already has communication protocols. It already has access through a firewall for internal networks. And I can even get to a BYOD, or wherever my target lives. You know, if they've got a laptop and it's sitting at their home, or it's at

Starbucks, or it's inside the network, you know, that's where it already has access to those points. Then it has third-party access. You know, there's tons of services out there that can save to Google Drive, copy from Google Drive or OneDrive or whatever. There's tons of integration points already to it for me to interface with. Um and so really all that hard work of establishing this type of a network is already done. I think the big thing here when you look at it is I already have access with these solutions inside a corporate network. Um my access past that perimeter firewall has pretty much already been guaranteed. Okay? And so, when we look at the holy grail

here, it has all the right pieces uh to this puzzle. You know, um the providers, the vendors of these services have already established um a server uh network for us, a command and control network. It already uses common protocols. For the most part, these things are free services. All an attacker needs to do is leverage this is create himself an account in one of these solutions and he's got he's I mean technically he's got his own he's got his botnet there. Okay? So then how does this attack take place? What needs to happen for an attack like this to to kick off? The first thing here is um why use passwords when we can actually

use the token that these services leverage? Um and we'll take a moment here on this slide and probably talk a little bit about how some of these solutions work. It may not be where I wanted to start, but that's where I will start now. Um whenever you bring up your login screen to Google Drive the first time you sign up for one of these services OneDrive, we're all familiar we're all presented with that log in with my username and password. At that point um and Dropbox is a an edge case. I'm going to focus a little bit on Dropbox a little bit, so specifically the ones I researched for this presentation was OneDrive um Google Drive and Box.

Um and then Dropbox is a is an interesting use case personally for me. Um it after this I've I've grown a little bit more fond of of how Dropbox handles their user authentication and their application security. It to me it stood out. Now for OneDrive, Google Drive, Box, all of these use OAuth 2.0 uh for their user authentication and specifically for their application authentication thereafter. We realize when we download the application the first time we log in that's a one-time thing. After that my thick client on my laptop or my phone will continue to connect whenever I come up. I'm not going to have to reenter my credentials. If that's the case, it's broken. Right? That's not how this is supposed

to work. The application is able to authenticate with a set of permissions from my user account and grant me access to um my share to my files to be able to work with them. Um and at that point when we do that first initial login, the reason that happens is because I'm granted an authentication token from those services. Um each service is a little bit different in how they manage and where they store that information. For the most part, OneDrive and Box stores that in the Microsoft credential cache. Okay? The web the credential cache, the web credential cache uh to be specific, it stores it there as a token. And in there if you were to go in and

log in and see your credential cache today if you had one of those services installed the actual password that's there is your refet refresh OAuth token and that's what is leveraged there. Um so to authenticate it just presents that token. It leverages the refresh token so it can request an authentication token. The time period difference is every 6 months. The application just does that and to the user it's seamless. There's no additional um issues there uh to present. So why is that important? So from a password perspective, you know, passwords are great for human interaction. Uh we're not going to talk about the um issues of passwords here though but I know there's too numerous to mention,

but from a password versus token perspective um it's easy to remember. It's great for um you know, a a one-time authentication let me in this time for session perspectives. Uh but what tokens are for and why this whole OAuth thing came about is for application authentication. So when applications need to authenticate back and forth every time I wanted to open my thick client OneDrive I had to enter a password we'd get we wouldn't use the service. And that's where OAuth comes in. It doesn't need to change frequently. It's difficult to remember, impossible to remember really I would say. Maybe some of you guys could, but you know, it's it's all uh stored there in the application for that purpose.

So how this happens is exactly what I described here. First time I log in, I'm presented with my login page the app the service sends back my token and then I use that token on subsequent visits and how that application will interact. Okay? So um so so for some security points here um passwords may require you know, two-factor authentication. It's only available when the user types it in from that standpoint. So if you were going to try and you know, use this attack with a person's username and password you would really have to be sitting in there and capture it as they enter this in. Um and even then you know, if you use go through and try

and leverage this attack through the web browser, eventually you're going to be timed out. It's a lot of easier for these services to implement those controls through the web browser because that password can be you know, you'll be kicked out of your session eventually. Whereas with a token uh it's seamless. You you can't implement two-factor authentication or single sign-on on a token application authentication. Uh it's you know, it's not going to happen. Right? Especially as with as this because this is that thick client communication from your laptop. Um it is additionally insensitive to new devices meaning that I can have my account can be logged into five, six, 10 of these different devices tablet phone laptop

and I can connect however I want to. I can use either one of those seamlessly. Whereas if I was coming in through a browser or something I'd have to reinitiate that uh every time. So it's insensitive to new devices, a new location for the most part. Uh much more difficult to apply some of those controls there that we would see normally. Um Okay, and most of the time yeah, like we said these tokens have a much longer life to live. You'll see you know, um 6 months out there on some of these. Okay then so what what kind of attack are we talking about here? So really what this is this is talking about um an attacker gaining access

to your um OAuth token and then using that token to authenticate as you to your service. There's a couple different um consequences of that and things that can happen. First off that means that if I was to gain your token and enter that in on my Google Drive installation, when you sync a file it would sync also to my laptop. The solution to that basically attack basically that is all that's happened to Google is hey, he's fired up a new a new laptop here. Um there are some different changes um that need to take place um on the each system's a little bit different um on where they store some of that client information but none of that

is uh inaccessible. Um from that standpoint it's just simple registry changes or getting into the application settings. Um and and telling it you know, where where your Google Drive folder is and so forth. Everything that's a lot easy to is very easy to get. So we're saying here we're going to synchronize the victim's machine with the attacker controlled account. Um we can relatively then get to sensitive data control the victim's account. I could also then place things from my machine and have them then sync to your machine which is what we're doing here which is what we're going to see some of the things here that we did is place some of those you know, sensitive files, place our

attack code that way then on your machine it's going to sync through your corporate firewall. The only hope you have is maybe you're smart enough to sit there and have your Google Drive folder up in the whole time and see that another file synced in there. But because it's syncing from your account um even though it's my machine, the attacker's machine Google Drive just thinks you synced something from your second laptop to your current laptop. That's about all that is. Okay? So the first the step here attacker creates an account um and this is simply um creating his own attack. I mean sorry, his own account um in one of these file sharing services that he wants to target.

Uh he attains he obtains his own authentication token. Um and then however, you know, the the main thing here is um however you want to do this you either, you know, send the person an email they they execute this what we refer to here in this is a switcher code that then runs this command where it either has you know, your appli where it has your authentication token in the command it switches with his account and so then those things then whatever's in his Google Drive, OneDrive can sync then to your account and you have whatever was in his Google Drive, OneDrive, Box so forth. Okay? Um also we've seen here then at the next

step is when you do that switch, whenever you put your OAuth token in place of his, you copy out theirs drop that in the Google Drive first so then you have their OneDrive token. At that point you can do the same thing. You could compromise their account that way by on your machine leveraging their token. And then we kind of refer to that as a you'll see this here as a double switch. Where basically then the victim's account is is syncing from both places as well. So, we can leverage it that way. Um okay. So, this is just a really, you know, high level here. There is a white paper on there that kind of goes

out there on the internet goes into more detail on exactly some of the intricate features of each one. Um but simply here is a high level. Uh we can see here OneDrive, Box, Google Drive all use this OAuth 2.0 refresh token. Um this is what is stored as your password in the credential manager application in Windows. So, if you just go there look at that. Um it's what's stored there. Um and so you see here Windows credential manager. Google Drive is pretty interesting. It's just sitting there in the registry. Um and you can access that with the standard um crypt data protect and the crypt data unprotect um API calls there in Windows. Uh Dropbox here though is proprietary.

So, it's a number of different things here that they've done. They're I don't I don't go into detail here in Dropbox on this just because it was proprietary. Um and to be honest, I'm not sure if in today's iteration of Dropbox if the attack I'm talking about here is even possible. Uh there is a really good presentation out there from 2012. I believe it's referred to as um a look inside Dropbox or something like that. I should have had it here. But um where basically it was compromised. Um but then Dropbox came out like 4 months later and like wrote rewrote everything and it's like I don't even think that type of attack works right

now. Um Dropbox instead of using an OAuth 2.0 token has a concept of a host ID. Where basically every one of us has a unique um host and client ID assigned to us. And they do proprietary encryption, well not proprietary encryption, but they then store this in an encrypted SQLite DB on your machines and so forth. Um I believe it's probably still possible. Um but I didn't uh spend as much time on that simply because it was going to be more difficult. And I had a spare amount of time. So, then how does this attack work? So, from a Google Drive, OneDrive, Box scenario, um we obtain uh the victim's token. Again, this is done

um with a malicious code that would be sent to them either in an email, however it is, we can have them run it. Um phishing, social engineering. It's not going to be that hard to have them execute something on their machine um that then does this for us. So, what this will do is obtain um the victim's token. Um we put this in the synchronization folder. Um and then we wait for that a pile that file to appear on the other side of the earth. I have their token. Uh this happens is because that switcher replaces their token with ours at this time. And so, it's actually, you know, their machine your machine will be

synchronizing with my controlled account. Um and then once we have that, once we have that token, we have access uh to what they're looking at, to what they need. So, again, the OAuth refresh token is going to be stored here in this registry key. Um it is a combined blob of a number of different pieces. Um but the second part in there is what you would need if you were to uncrypt this with the crypt unprotect data call. I had a PowerShell script that I ran this with. It was pretty effective. Um and then what this does is we we're just going to replace that token with ours. Uh and then they're going to sync to our

account. There's nothing much more uh difficult than that. Uh there is um like it says here, um the sync config uh DB for Google Drive uh simply um we replace our values in there as well. This is a simply file write and replace. We leave the we leave the root path in place in case they have installed this in a non-default area. Then we're going to go to that same location for the Google Drive data. All right. So, uh the double switch here again, we have the malicious code on place. This syncs to the cloud with our client ID. I get this on my end. I leverage this. And I can come play stuff back and forth

between the accounts. Um At this point, um what can happen is and the reason for the double switch is important. If you are going to do an attack here where um I just want to get whatever's in their Dropbox. There's no sense in I don't care about their token. I'll I'll I'll drop it in there run the code replace it with mine. I'm going to get synced to my folder whatever was in their Google Drive or or OneDrive any of those services. Um if I want to um not have the user if they were to to to um connect here or to um you know, if they were to use or to or to change any of the services, there is

some things that they could see where I realize now that the it's not syncing to my account basically. Um so, the purpose here the double switch is to basically switch it back. So, we're looking to have a persistent scenario where I can control that person's machine um at will without um with really without them knowing it. Um so, if we're looking at duplicating a bot scenario and having that command and control control set up in place, what we're saying here is if I compromise 50,000 users this way, I'm going to have 50,000 users syncing to my one controlled account. Um but I'd be able to put something in there and then have that sync out as

well. Um so, with the double switch here, what we're saying is that my my account is also the victim's account. Okay? So, I'm controlling my victims with with that authentication token. What that allows us to do then is have that ability to execute remote code. So, here we could have um a scheduled task that runs. I simply drop my executable into that victim's shared account. It will sync inside the data center to wherever their devices are. It'll run that code. It'll put the output back in the back in that same file, same location, and then sync back to me and I've just exfiltrated uh whatever it was that my code wanted to grab. Okay? Um so, some other things um out here

again. So, instead of, you know, having us send um you know, one thing we're looking at here is being able to, you know, have something sync to um through the victim's account to the attacker's controlled account side of the house. And instead of sending code or a malicious uh script, uh we just inject something into a file that's already there that we've seen that the user opens. So, then if I'm a macro or something, they run that and it executes. Um as well, uh ransomware. I don't think I've seen too many of the cloud ransomwares, but I I don't expect that to be too far away. So, we have a little video here. We're going to walk through some of this.

Uh this is with Google Drive. And um I'll just uh speak to this. If there are any questions at all during this, don't hesitate to to ask. So, let me get over here and we'll we'll start this.

So, the first thing here, um we prepared the payload. Uh this is my token. This is the OAuth token right here that I'm going to replace with the victim's account. Um so, this switcher application is what needs to be executed on um the victim's machine. Uh we can disguise this however we want. You know, click this and you'll win a million dollars. It it won't take that hard for somebody to execute this. Um we see here this is this is um my my Google Drive folder here. We see that it's empty. Whenever the user runs this switcher program, it will execute and show up on my side. Uh whatever's in his Google Drive folder will now appear

in mine. All right. So, he executes this elevated privileges. Um And then obviously inside here this the code is now run. It is already executed. Um we can see now that this has shown up in here. This is his token. And I've replaced it with mine. So, unbeknownst to him at this point, let me see if I can pause it right here. Yeah. So, unbeknownst to him at this point, right here, this is now syncing this is the victim's folder is now placed in there. My his old token's now I'll have it. Um any other output we want, anything else that's in there. And this is going to show up on this side of my blank

Google Drive. All right. So, I'm sitting across the world at this I could be anywhere and it's just going to sync to me.

So the victim's data has showed up. We can see his files inside there. And and all the Google Drive is concerned about or cares about is that hey, here's another application. Here's another device that has connected. So part of the double switch here. Right, so now I can send something back. Right, so now I'm putting something inside my synchronization folder and now this is going to go over and show up on the So this is the command here I was talking about. Now it shows up on the victim's computer. Now let's run something and it's sending me output back through Google Drive. And this could be, you know, the first steps and whatever else you want to you

want to grasp. But simply stated, that's how we exfiltrate then, you know, any of that sensitive data that we're after. Um could be part of any type of recon perspective to get in and move laterally. And so what does this look like on the victim's machine? What what traces are left from this? And this is the thing I I thought was really surprising. Um the only thing we see in here is the link to um the script that was run that no longer exists. Okay, so once we pulled out, that that's all we have left in there. Um so let me stop there. You know, first off guys, any questions on that? Is that is that uh following?

Yeah, great. So um there you you you would So you whenever you do the switch, you also want to grab the victim's um token so you can basically roll it back. Right? So you'd want to have have a command that goes in there and just does the opposite of what you did before and then it's restored back to his account.

So um one thing in here that I've seen as well as you can you can have a scheduled task. So if you get in there, you can set up a scheduled task that looks for a file that drops in there. Um that that would be one way to do it uh without having them have to click on something. So that's part of the evolution of this is I think um you'd want to if you would like So just like we did like with the PDF file there, if you if you see a file in there that you think that they're opening frequently, then put your code there, right? And as soon as he opens a file that's synced in

there, it runs that as well. And so you can easily hide hide those attacks inside of those files. Okay. Any other questions? Thanks for that. Good. All right, so uh how bad is it? Um how would you go about detecting this um and and mitigating an attack like this? Um So first off, um proactive. How can I be proactive and stop this? There's nothing. If somebody captures your OAuth refresh token, you would have to be a reactive scenario and revoke that token. Um There's there's really no other way about it uh that I've that I've come across. And if somebody else knows, please let me know. Um on Dropbox, um somebody's going to either have to

um have pulled out your host ID from that encrypted SQLite database or attempted to spoof it. Um and and kind of like what you see here, some of these in the it's pretty limited. I mean, there's not a lot of good stuff here, but you can go into OneDrive, Box, and Dropbox and see a location of where you've been connecting from. And if in there it shows up that I was connected in Salt Lake City and Poland and you've never been there, you're that's when you know, okay, I need to go revoke my token and get and get that taken care of. Um So you can if you disconnect all of your devices, meaning that you

uninstall the compromised app across all your devices and you log back in new, it will generate a new authentication token and a new refresh token. So if you've got five devices, you uninstall Box from five devices and then you come back in, now you're new. Now you've revoked your token. Um Google Drive um you can just uh disconnect these devices, but the one thing here that we did find out with OneDrive um is that if the session is open. So meaning that um I've disconnected all the devices that I know about, but there's a sixth. It's going to you're still there. So if the attacker never relinquishes control, um it's going to hold on to that refresh

token. Um Okay, very good. Um and then again with Dropbox, um this isn't so much applicable because it doesn't use OAuth, it uses the host ID. Um I'm not really sure if somebody got a hold of that, I'm sure there's probably disconnect it, you'd be okay. Um but it it uses the host ID, not an OAuth token. Okay so the other thing here, right? So when we think about a botnet, a botnet can be taken down. Um you can remove the command and control servers. You can Yeah.

Mhm. Um yeah, so in that regard, right? If if my machine's compromised and I know I'm syncing to a device that's not mine, I could drop in some type of malicious code and if he opens it, then yeah. Uh that's a good point, right? Yeah, so there is that capability. Um So from an I from a take down perspective, if we were going to I mean, we can't take down OneDrive. We're not going to take down Dropbox. Um the IT infrastructure of a botnet per per um perhaps so can always be compromised or taken down. We see that a lot where they now have a signature for that type of a botnet, we're stopping it

left and right. Um From a from a an attacker perspective here, um this does say here you know, never compromise, but obviously we can send stuff back. Um but it would be extremely difficult to What do I mean by an attacker account? It When I when I said this here in this in this standpoint, it was identifying an attacker. So a OAuth token, a refresh token um by itself is not going to and identify the user cuz it's identifying an application. Um if I acquire the victim's OAuth token and now I'm using that to sync back and forth in not my own account, um obviously the attacker themselves, you're going to get the location, but

that's about as close as you're going to get to the attacker. Um Okay. So from a summary perspective, um cloud file synchronization services um for the most part um are still vulnerable. There's there's not a These companies have focused on the user experience and like we've like we see left and right with security instead of how they're going to prevent um and and and secure these types of attacks. Um Compromises are achieved through tokens rather than a password, so it's not something you know. Um And because of that, it's very difficult to um detect these types of accounts. We saw a little bit little bit of this by an analysis by Blue Coat in the Inception

framework. There was a company There's a company out of Europe called CloudMe. Um I don't really I don't think in the US we use that too much if anybody does. Their big uh point is being GDPR compliant, which is another conversation as well. Um be being based in in Europe and that framework was was utilized exactly for this to exfiltrate data. So once they got access to the machine, they would drop the um output, they would drop the data they're after in a CloudMe share that the attacker controlled. And that's how they got it out. Lasted for quite a long time. Um and it's a good read if you have time for that. Uh endpoint and perimeter security

measures are are kind of incapable here and the reason is because we're leveraging uh the same type of protocols. We're using the same servers that if you would turn off, you know, you're going to turn off your investment in Office 365 basically, right? So there's no there's no shutting down or um mitigating this in the in that standpoint as well. Um if you have um So let's let's talk a little bit about some of the solutions out there. There is a market out there referred to as cloud application security brokers, CASB, if you haven't familiar with it, it's a pretty new one. Um been around for a little while, but uh still still fairly under the radar.

The point here is that um basically you're setting up a a proxy or a think of like a DLP gateway in the cloud in front of these solutions that you are directing your users through. Uh that can be done either through um reverse proxy scenarios that you use in like the box and the OneDrive business applications or that you set up through a um an agent on your company owned devices that forces that traffic through these vendors. The ability of the the point of that is that you're then able to um really uh have an insight into what is leaving your organization and synchronizing to the cloud and also based on that, if I'm coming from a

device that isn't approved, which is what the attacker in this scenario would be, even if I'm coming in as the victim, if I'm not coming from an approved device, then those solutions have the ability to terminate these connections and to stop this type of an attack. Um and that's you know based on device recognition and so forth. Um So I'm not here preaching that, but my mitigation perspective is to look at one of those solutions to help with that type of um uh mitigation. So um basically it comes down to kind of what we're seeing here, two-factor authentication for new devices. Um even if the access token is there, if I'm coming in from a new device,

um it's going to require some type of a step up or just complete revocation of that um of that new device. So that's one thing I've seen here that I think would really help with this that I don't see in the market enough. Um a lot of the um companies that I work with, you know, they've rushed to some of these solutions to pacify their users. Um and even then I come into a lot of companies who um you know, we we provide we provide OneDrive, everybody gets their OneDrive account, and then I go and I talk to another division and they've gone out with a company credit card and they have their entire dev team using Dropbox

unbenounced else and they're passing IP-protected data go across just like this and it would be so easy for an attack like this to succeed in that standpoint and come out with tons of intellectual property and so forth that sits there. I worked with one customer who had who promised me that they were using no cloud solutions. They had their um you know, their internal file store and everything set up and it took me about 10 minutes. I walked into their head um financial wasn't the CFO, I'm thinking, it's but their head accountant and he had past audit and accounting documents sitting in Dropbox up to like 10 gig of all this accounting info just sitting in there

and it would have been a landmine for an attacker like this to come in, target that person's title off of LinkedIn, send him something, he clicks it and his 10 gigs have synced to the attacker's account in about, you know, 5 minutes probably. So it wouldn't have taken that long to really exfiltrate this type of key key information that we store there. Um so again here hitting on the CASB is anomaly detection, device control, and then block and alert on rapid changes in location um is how this can really happen. You know, your attacker isn't going to be sitting next to you. Maybe at B-sides he will be, but in the real world, you know, he'll he'll be far away.

Um and so why is this important? It's all about the data. It's about what we put there. If we are storing sensitive information and we don't have security controls in place, then we're at risk. And that's how this that's how this goes. If you don't have a cloud security strategy, get one cuz you know you're going to be going to the cloud. Um the benefits are too great, the cost savings are too great, but if you haven't discussed how we're going to control our employees and our organization, how we're going to secure that when we do go there, uh then then we're at risk. Um you have to assume that sensitive data is going to be stored there. You

have to assume um that it's not just going to be for, you know, sharing pictures and cat pictures and whatever. Right? It's going to be sensitive business data will be in these solutions. And I've talked with lots of customers and and and companies who um they they have the whole third-party liability thing confused. They think because I'm storing it there that Microsoft is in charge of protecting that data and that, you know, Box is the one liable if my data gets compromised. Uh and obviously that's not the case. You know, we are still in charge of where our data lives. We're still um responsible for um storing, protecting, and remaining compliant with um the regulations that we fall under wherever

our data is. So if it's in these solutions, which we know it is, then how are we securing it today? Um so that's what I got. Questions?

Uh I I have not. I I I personally have not. I'm sure there's other ones out there that are not susceptible to this and have different uh advantages over the others, but yeah, I just I just didn't during this. Yep.

Good. Other questions? All right. I think I'm done a little bit early, but um there it is. [Applause]