 Yeah, so please join me in welcoming Michael Bargary for Low Code High Risk Enterprise Domination via Low Code Abuse. Hi everyone. So first of all, thank you for staying. This is a difficult time, but we're gonna have some fun today. So this talk is gonna focus on how do we take Low Code, which is kind of technology that are about enabling users, users to build their own things, and seeing how attackers are using that to basically own the enterprise. And this entire talk is based on attacks that we've observed in the wild that we are going to recreate today. My name is Michael. I've been doing security for a long time now. I spent a few years at Microsoft on IoT and APIs and cloud. If you've seen my first talk this morning, so thank you again for coming. And I hope I don't bore you. Other than that, I've started a company called Zennedy. A year and a half ago, we're focused on Low Code, No Code Security. That's how we got to observe this space. And this entire research is going to be, is featuring research from Real Zilberberg, which is sitting right here. So give him some love. Thank you. And I'm really excited to be here, my first DEF CON, so it's been really amazing. A short disclaimer. This talk gives an attacker perspective on Low Code, but of course we are all for Low Code development. This is the trend of Low Code is really cool, providing users the ability to build stuff on their own. But it's important to do it securely, so that's why we're giving this talk. Here's what we're gonna do today. We'll start off with making sure we all understand what Low Code is. We'll then dive into attacks that we've observed in the world on Low Code platforms. We'll start with leaving of the land attack, so cases where attackers are using Low Code to basically do whatever they want inside the enterprise. The second part would be how do you remain persistent? How do you establish persistence here through Low Code platforms? And then we'll go to predictable misconfigurations and how those are abused through outside scanning. We'll finish off with two things. One is you'll have a couple more tools in your red team arsenal to play around with. And the second thing is how to protect your organization. So we'll go through that as well. So let's start. Low Code is really all about empowering of business users. So the idea is basically business users are tired of waiting for IT. They want to solve their own things, their own problems. And so they have these drag and drop interfaces which allow them to create applications and automations. And the crucial piece here is that it's built on top of platforms that you already know and we'll see that in a moment. If this idea of enabling business users to build their own things sounds familiar, well, there's a long history behind it. So there are these, there were software that allowed you to record your keyboard and your mouse and then reiterate that for automation. There are macros which are of course our close friends. And there's Low Code now that is on the same axis. And people are building all kinds of things with it. So if this and that automation, for example, every time I get an email with an attachment, store that attachment in Google Drive, applications like handling receipts or onboarding and onboarding users, there's really a lot, lots and lots of business cases for these kind of applications. And the crucial thing is this is already in all of the enterprises in the world. And it's not because they made the kind of conscious choice to do it. It's because the vendors, the vendors that you're seeing up here, but also others have basically built a Low Code platform around existing services that they already have. So if you're a Microsoft job or if you just have office, every user can build automations and applications based on their own identities within office. And this is something that you already have in your organization today. The same thing applies for Salesforce and ServiceNow and all of the logos that you're seeing here. So this is by definition also already inside your org and touching business data. So here's a very quick recap on what Low Code is. We've discussed that it's available in every major enterprise. Actually what we're seeing is that in every organization that we're starting to work with, there are tens of thousands of these applications and these are not exaggerated numbers. Tens of thousands of applications being built by business users. People in IT, people in HR, they're all building their own things and you will see in a moment that it takes just a couple of minutes. We've seen that this is, this by definition has access to business data or power of business processes because that's what it's meant for. And it runs as SAS, which is important because all of the controls that you're used to, well, they're not there. This runs on the vendors cloud. So on Microsoft's cloud, on Salesforce cloud. And the last piece is that this is vastly underrated by IT and security teams. So people have started noticing this area, but there's a lot more to go there. So that was the recap. That was the kind of figuring out, making sure we're on the same page on what low code is. The next part is observing attacks. And before we are going to, and by the way, this part will be heavily focused on Microsoft Power Platform, which is built around Office, simply because many people are using it. It's very successful. And so hackers are using it as well. Before we start figuring out how our hackers live off the land of low code, no code, and specifically Power Platform, let's just make sure that we all understand how this looks like. So this is gonna be a very quick example. And let me play while I explain. Basically, this is a very simple automation. It's gonna be built in a couple of minutes. This automation does one thing. When I'm in Slack, and somebody mentions me on a common channel, it's very annoying because I always have to respond quickly because it's in a common channel and everybody's seeing. So this automation, every time that somebody mentions me, it changes my status as if I'm on a call, then that person could figure out that I'm not available right now. And then, of course, it moves me back to a status that is clear, so nobody will suspect anything. And you're seeing that in order to build this automation, I'm kind of dragging and dropping. I'm going through select boxes. These are things that everybody can do. And that's the power of this technology. That's also the risk. One of the key parts to notice here, and I'm gonna stop it somewhere along the way, is the fact that you haven't seen any sort of authentication. Keep in mind, this is kind of, this is Zapier, one of those platforms, going out to Slack with my own identity and changing stuff, right? But you haven't seen any window pop up. You haven't seen any overflow. So how exactly does this happen? This is very important in order to understand how attacks are being made on those platforms. So here's a step-by-step of what happens when you create a new automation with low code. The first step is that you pick from a list of lots and lots of applications. Those could be SaaS applications, on-prem connectors. Those are basically hundreds and hundreds of connectors that are being provided by the platform themselves to connect wherever you'd like. The second thing is that there is this over-consent flow that basically allows the application to operate on your behalf as a user, but notice the last part, and specifically the share button. So something is going on here, right? There's an application. It logs in on a user's behalf to Slack, and then somehow it's able to share that user's authentication with Slack, with other users. And so the next thing we're going to try and figure out is how does this work? So on one side we have Zapier or Power Automate or other automation tools that are part of low code, and on the other side we have Slack, and again the idea is to figure out how does this authentication work, and especially how does connection sharing work? So here's how they do it. Instead of going through the usual route of kind of RBAC and asking for permissions for each user separately, they simply copy the refresh tokens and then replay them. So you plug in, you do the consent flow for Slack, Power Automate will store your refresh token, and then you can share that refresh token with other users through Power Automate. Now of course from Slack's perspective, or from a network security perspective, there's no sharing here, right? It's the user, the user is always the one that's doing the operations. It doesn't matter if an application is using it, if other users are using it, this is a crucial point. These applications are basically blocking, are basically breaking the permission model that we're used to in SaaS and in connectivity between applications. Okay, now that we figured that out, let's see what attackers are doing with it. So the first thing that we need to understand is that because lots of, you've seen how easy it is to create these applications and lots more people can create these applications, that means that you get lots and lots and lots of applications. These are all examples from the marketplaces of the different vendors and maybe you can see the numbers, it might be too small, but there are hundreds of thousands of those being deployed and again we see that in enterprise all of the time. And the important thing here is actually the logos because behind every logo in these processes there's data, there's connection to data or there's the ability to do all sorts of operation. So behind every one of those applications, those tens of thousands of applications within enterprises, there's a trail of connections, a trail of connections that can be shared with other users. And actually it's not only that it can be shared, in many cases that's the default. So if you'll see, if you look at Microsoft Power Platform for example, if you look at Zapier or at other platforms as well, they all have a notion of a default environment. Some place where you create an application and you don't think about it, the connection will go there and other users can just pick it up and use it. So those are examples of the default environment from different vendors. Again, this is not something with, this is not a problem with one platform. This is a basic concept of how this technology works. And so every platform has their own version of this default environment. And when you have access to this default environment, you get access to tons and tons of connections across the organization. And I'm talking about from what we've seen, SQL servers with root accounts, users, their users own identities to Office and to Slack, FTP connections, all of the things that you could think about that users are using these platforms for. So what we're seeing hackers do very easily is once they get into an enterprise, once they find at least one user's account and they're able to log into their SaaS, they can very easily escalate their privileges. Like it's already there, it's built in. So that's really, really, really simple. But the next thing that they'll do is that they'll use these connections that are part of the platform and they do a bunch of things with it. So here's an example of a ransomware attack. And again, these are all attacks that we've observed and recreated. So in this example, I'm going through a SharePoint site on a schedule and I'm simply encrypting every file on the SharePoint with the comfortably provided encryption function within Power Automate Microsoft's platform. So again, ransomware here is just really, really easy and this is ransomware without installing any agents, without going through the network. This is all on the SaaS cloud. The other thing that we're seeing people do is expert data outside of the organization. This is a crucial piece. There's a bunch of, so when you think about how do we protect from data leakage, we can go at it through the network, we can try and scan storage accounts and cloud accounts. But because these platforms, they mix up identities of different users and you can also plug in your personal identities, then you don't really have access to scan everything here. So for example, in this example, which we've seen, I think in every organization that we're working with, we find what people are doing is in order to send email, a corporate email to their Gmail account, they're simply copying the content instead of forwarding the email. And then really there's nothing you can do outside of the platform to even catch this because remember, this is impersonating the user. It's not going through any sort of approval process. So data expression is really easy here. We've seen this not only with emails, but you can do it with other things as well. So for example, creating a useful application and then even by mistake storing its data in your own personal Dropbox, because you can mix and match these things very easily. So we're seeing this again multiple times. Another thing you can do, which is actually kind of weird, is that you can jump from the cloud to people's laptops. And that's because these platforms have a component that's called RPA, which is about automation on the user side, on the laptop side. We actually had another talk on this earlier today. So you can, the materials are there in the link and you can find it online. But it's very easy once you have access to those shared connections. Some of those shared connections are actually privileges to execute something, a payload on a user's machine. And then you can just pick it up and use it. Again, the same thing that we've seen for lateral movement. So as you can see, there's a lot of risk in these overshadowed connections, which are, again, recall, these are wrappers around authentication, refresh tokens. This means that from the outside, you won't be able to figure out that there has been a share. So that's one user that's simply reusing that connection again and again. In order to make it easy for us and for you as well to kind of figure out whether this happens within your organization and to plug it into part of your kind of red team arsenal, we've built a small tool that basically allows you to plug in a user and get a table with all of the different connections that that user has access to, which users are, those connections belong to. So that's all available very quickly. You'll see that tool, it's kind of, it's less than a hundred lines of code. It's very, very, very easy. So feel free to kind of use it and play around with it. The next piece I want to talk about is how do we make, so let's say that we got into an organization and we're seeing those shared connections, but we want more. We want to find, we want to entice users to create those connections and we want to own a specific user identity, for example. What we can do here is we can set up a beta application that basically asks for, for example, your email connection with a good reason for that, but then we can use that email connection while the user is connected to do whatever we want. Of course, this is not special to low-code applications. Every application can do that. The key thing here is that somebody from HR can create this application, somebody from finance. So there's a much lower bar to create these applications. And there's also another crucial piece here. This is all run on the vendor's SaaS products. So for example, in the example that I'm going to show you, it's about Power Plus or Microsoft's local platform. The application will end up in a Microsoft.com domain. So users will trust it, why not? So let's see how it works. So while this is running, what I'm going to do is I'm picking an application from the template list. I'm specifically taking an application that is about creating an out-of-office. So you go into the application, you give it access to your email, and it will decline emails for you. You've seen briefly that I needed to create those connections to click allow. We'll see it again shortly. So you see I'm picking a date and then I can configure a few things and the application will do everything for me. And this is a useful application. I didn't create it, I just picked it off the marketplace. What we're going to do is take this useful application and abuse it for our own needs. So I'm hitting the edit button here and I'm going to do a very simple thing. I'm going to use the user's email while it is connected to send myself an email saying, hi, I've been pwned. Now of course, I could have done other things here but the important thing to note is how simple it is. So it's a single line of code to reuse that user's connection to do anything we'd like and the user don't really have a way to know what's happening here. Okay, so while it takes me a lot of time to type, the next thing that's going to happen here is that I'm going to save the application and by the way, when I click save, it's already deployed so there's no deployment process here and then I'm going to share it and I'm going to share it with the entire org because that's a function that's available here so why not? Once I create this share, Microsoft provides me with a nice link for my application. So I'm going to copy that link and now I'm in another user and I'm going to plug in that link on the browser and let's see what happens. First of all, I get this window that's asking me to use my credentials and it was asking me for two things for my account to office and for my calendar. And of course, while I click allow and I use the application, very quickly I get the email that have been phoned. So we've seen how easy it is to do it but there's one key thing to understand about this example and that is this window, okay? This window is what allowed the application to take over the user's identity and as you can see, this is not the usual OOF window that you're used to. It's not telling you, hey, these are the operations I'm going to use so you'll know that other operations are being created. No, this window is about sharing the connection, the connection that we saw earlier. And so the only thing that gave the user a hint that I might be able to steal their identity is this window and so naturally we want to figure out a way to remove this window. Note that if I'm able to do that, all I have a link on Microsoft.com and if I'll share it with anybody in the organization and they click it, that's it, that's game over. So thankfully, this is something that's already available. This is for Microsoft Docs so an admin can basically set a flag that means that this window just goes away. And actually people are doing this in order to make these applications easier to use. So if you're in an organization that has done this, you might be in big trouble. So we have seen multiple ways in which hackers are leaving off the land. Specifically, we've seen things about Microsoft Power Platform and we've seen it about Zapier. We've seen lateral movement, privilege escalation, run somewhere, account takeover. And these were all drag and drop, very simple, very easy to use. The next part that I'm going to talk about is how do we stay there? So this has been, as you can see, there are a ton of things that you can do once you get into those applications, into those local platforms. And the next part is how do we make sure that we remain persistent within those platforms? But actually it's more than within those platforms is to remain persistent in an organization. Because again, if I'm there, I can use the connections and continue on from there. We are actually not going to invent anything here. This has been done by an APT group about two years ago. So what happened here, and if you'll follow the link, you'll see all of the sources. Basically, this is a slide from Microsoft Detection and Response Team, where an APT group was able to stay hidden within an enterprise. They knew that they got hacked and they were looking to find the hackers. And it took them six months to find that there was a single automation on Power Platform that did a very simple thing. It used eDiscovery to go out and find secrets and find business data in email, in Outlook, in ShellPoint, and then just send it off to a random endpoint. And nobody was looking for it. You don't really have a network appliance looking at what Microsoft is doing. And so this took a long time to find. So what we're going to do now is recreate that and see exactly how it works. Here's the first version. So on schedule, I'm going to go through all of the files in a single ShellPoint site. I'm going to encrypt them, send them over to a random endpoint, for example, Pacebin, and I'm going to tweet about it because why not? I mean, nobody will find me anyway. You can also apply this to on-prem. You can plug in any one of the connections that we saw before. So this is actually exactly what the attackers have done. Now let's take it a step further. So instead of starting with a schedule, let's plug in an HTTP endpoint that you can just call from the outside. And in this example, what it's going to do is encrypt an entire Google Drive. Again, why not? So this is basically encryption run somewhere for a specific Google Drive that is available through an HTTP endpoint outside of the org. But actually, I've mentioned that this part of the talk is about persistency. This is just a very small part of what we need in order to remain persistent. So here's a laundry list. Of course, this is not everything, but there are a few things that we need to be able to do. We need to be able to run code remotely. We want to be able to run arbitrary payloads, not just a fixed list of payloads that we've described earlier. We want to maintain access even if the user that created that gave us the initial access gets blocked or removed or whatever. We want to make sure that we avoid detection and attribution and of course leave no logs behind. So let's see how we can do that. We've already seen a first version of persistency because there's this HTTP endpoint. Let's try and figure out what does it cover from our laundry list. So I'm able to execute things remotely. That's pretty obvious, that's an HTTP endpoint. This is definitely not an arbitrary payload. This is a specific payload that I've created and that's the only one that I'm going to be able to run. In terms of maintaining access, that's covered here because all of the, because that HTTP endpoint comes built in with a secret. So we don't really need to be authenticated in order to call that HTTP endpoint. Again, something that is the same in every local platform that we've observed. And so I can very easily just call that endpoint and that's the only access I need. Avoiding detection is again very easy because it's somebody else's cloud. You have no security controls there. Avoiding attribution is also very easy because that's a single, that's an endpoint. You can call it from wherever. They're not blocking tour or anything like that. So just go ahead. And in terms of logs, not really. We're kind of in a problem here. Those automations generate a ton of logs. So I'm talking about every single piece of information that goes through those automations is actually being logged there, including the data itself. So we need to figure out how do we tackle those two points, the arbitrary payloads and the logs. Here's one attempt. We're just gonna have a single endpoint but this time we will implement a whole bunch of payloads. So there we can think in advance about the payloads that we would like to execute. So one of them is leaking an entire SharePoint site, another is encrypting an entire SharePoint site, executing a SQL on a random database. All of those things are available through a single endpoint. Actually I didn't have, there's no advancement here, right? Still no arbitrary payloads and I really haven't touched the logs thing. So let's see how both of these things can get solved. And for that, I'm gonna use a very useful piece of software from those local platforms, which is the fact that the local platforms themselves provide a way for you to manage them through low code. So you can use low code to create new low code applications, you can trigger them, you can delete them. And so I'm sure you'll see where I'm going with this but I'm gonna take you through it anyways. Here's what we're gonna do. So I'm going to show you exactly how I cover both logs and the payloads. This is already out there so you can go ahead and use it and this tool basically allows you to install this backdoor inside of an organization and then you remain persistent. Here's how it works. I have a single endpoint, an HTTP endpoint and instead of running a specific payload, it's running a payload that creating a new payload. So I'm passing through the definition of the automation, which connections it should use and then what this automation does is creates that new automation and triggers it. I actually need more than that so there are three different things that this covers. One is creating the automation, the other is deleting the automation and another crucial piece is just listing those credentials, those connections that are laying out there so we'll always be able to use fresh ones. And of course this completely covers the general payload so I can just run whatever I want now. Sorry. One more thing that we need to, one more thing that's covered here and I haven't actually specifically described it is because I can delete the flow after I run it, all of the logs get deleted as well. So the logs are actually maintained as part of the flow itself and so by executing the flow and then deleting it, I'm remaining completely, I leave completely no logs behind so the only logs that are left are the fact that this flow is running and this can be hidden by basically saying, okay, this flow, don't remember anything about it. Here's the entire flow, the entire automation. So again, one HTTP endpoint, three main commands, created automation and trigger it, get connections so I can create new automations with that new connection and delete in the automation. Here's the same thing with a Python wrapper that makes it easier for you to use it without going through the UI for Microsoft. So this is kind of small so let me make sure that you understand what's going on here. I plug in the web hook that I got from installing this backdoor on Power Platform and then I create a flow, I trigger it and I delete it all within the comfort of my Python CLI. And this, of course, is all available for you to use right now so I'll describe briefly what this thing, what you need to do in order to use this. Basically, once you have access to Power Platform, you follow a small guide that I have there that's about installing that vector that's basically uploading that automation that you just see here and you get in response the web hook and then you can use it. So, and again, keep in mind, this is far more advanced than what we've seen the threat actor actually do and the basic thing that the threat actor did took defenders six months to find. So I wonder how much this could take. Okay, so we've seen two subsections right now. We've seen how hackers are leaving off the land of low code to create or to run their own malicious operations based on the local platforms themselves. We see now you can stay within these local platforms, remain persistent. The last thing I want to cover is how does this look like from the outside? So, sorry. So both of the sections before started off when I have some sort of access to the platform, but actually there's more going on here because business users are creating these applications, there are common misconfigurations that we can find that we can look for and that are predictable that expose business data outside of the organization. And actually we've seen this with AWS three buckets a three buckets, right? So the default was insecure every new bucket was public and then even though they changed the default we're still finding these public three buckets today. And so the same thing applies here but the key difference is that these are not only developers that are building this, these are business users so there's a lot more of it. We'll see a couple of examples. The first example is Microsoft Power Pages which is basically a website that allows you to authenticate, it allows unauthenticated users to observe the website. This is being used for vendor management, contractors that come into your office and that's an entire application that you create with drag and drop. Of course, there's a database behind it, there's a bunch of information there that should not be available to the vendors and the contractors. Actually, about a year ago, the team at UpGuard found that there was an insecure default there that basically meant that the entire, the database behind that application was available to anonymous users and this was the default configuration for about a couple of years. Now this was a major thing, about 40 million records were exposed by UpGuard's estimation and Microsoft has actually been very quick to change the default but of course the default is not everything. So there are still these applications that were created beforehand and users can always make mistakes. What we wanted to do here is to try and find out how many of these mistakes we can find. So how do we do it? Basically, we're going to scan the internet looking for portals, these kinds of applications that are exposing business sensitive data without any authentication and here's an example and this is actually a real example from a large financial services company. You can see that by querying the API I get three different objects that I can query. One is the default object, it's not really interesting, it has nothing there. The second thing is an entity form set which is basically the way to store form submissions. So again, not really interesting but the third part, global variables is kind of interesting. And of course when we look into these global variables what we found was authentication tokens for Azure and for Power Platform that were being used by the application itself. And again, this is available to anonymous users, we browse it through Tor. So very, very, very, and the crucial part here is that it's very easy to find. So why is this easy to find? Because it's all in the same subdomain. So every one of those applications is in this subdomain and the endpoint, the API endpoint is always the same as well. So of course we can do subdomain enumeration here. Here's a lazy way to do subdomain enumeration. We'll just use Bing and Bing because this is Microsoft so it works. So you're seeing about 60,000 different portals that are available out there. And we have actually been going out to people and trying to help them make sure that they are able to solve this issue. Here are the examples of what we found. So lots of, nice, lots of PII, secrets, API keys, authentication tokens, and lots of business data. So PDFs, pictures of recipes of receipts, so a whole bunch of business data. So again, this was a case where there's a misconfiguration that is very predictable and it's very easy to scan for it. Let's see another example. This time we'll focus on Zapier. Zapier is a tool that users, as business users are bringing into the enterprise themselves. And Zapier is again an automation tool. You can drag and drop and you create automations. Zapier has a nice feature called storage by Zapier. Basically, what this means is that if you need to store some sort of state for your automation or you need to store secrets for it to operate, then you can use this storage and the way that it's protected is that you need to choose a GUID, some sort of GUID, and then once you plug it in, that's a key value store, you get your secret back. Now, as you can see, I mean, GUIDs are not the best, but it's still kind of difficult to guess. When we've observed the API documentation, you can actually see that the example that they provide is secret equals one, two, three, four, five. This is definitely not a GUID. So, we were curious. The first thing that we tried to do is kind of just try a random secret and that's the error that you're getting if that's not a GUID. But actually, once you go through what we actually did is we iterated through a list of known passwords and what we got was that many of those passwords actually worked. So, you're seeing here examples of things that we found. Again, authentication tokens, API keys, emails, phone numbers, and actually what happened here was that, so, up until about two years ago, Zapier was not really making sure that users were using GUIDs. They could use whatever they want and then they started doing it, but they didn't block the old secrets. So, you can still use them and they are still available. I mean, some of them are available today. We have been working with Zapier Tune to make sure that this is covered and actually the vast majority have already been cleaned up. Okay, so we've seen two examples where platforms allow predictable misconfiguration and how from the outside looking in without having any access, we can go ahead and access business data. Here's a summary of everything that we've seen up until now. So, we discussed low code. We understand how it's pervasive in any enterprise and the fact that it's built around business data. We understand that it's kind of underrated by IT and security teams which make it a great target for attackers. We're seeing how hackers are taking advantage of it really kind of all around. So, leaving off the land of low code, for lateral movement, for privilege escalation, we've seen everything. We've seen how you can hide within those local platforms and use that as a way to persist within an organization. And we've seen how you can use those same platforms and the predictable misconfigurations that they create in order to find business data. There are two things. Actually, we've also seen two tools that we've released today. One is Forzaappia that allows you to find those connections, those shared connections. And the other is the backdoor that you can install on Power Platform. So, the last thing I want to do is leave you with some tips on how you can secure your organization, how you can protect yourself. So, here are very specific things that I really recommend you do quickly. The first thing is that you need to review configuration. For example, that Bypass Consent Flag from Microsoft, make sure that's off. There is also the usage of those connectors. So, make sure that connectors that are administrative, for example, couldn't be shared in a default environment. I recommend that you view those endpoints, so those platforms are creating for you. So, again, you don't have to be fully aware of it, but it's already there. The platforms are exposing these endpoints for you and you have no easy way to monitor them. The number one thing that you should take out of this talk is go through those shared connections, go to those default environments, see what users have built. You'll be surprised. And there's a bunch of more information that you can use here. There's an OS group that is dedicated to low-code, no-code that would help you figure out what are the different risks that are around the space. And there's a whole bunch of articles there that could help you. So, thank you, everyone, for the time. It's been fun. Thank you.