Yeah, so please join me in welcoming Michael Bargery 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 going to have some fun today.
So, this talk is going to 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.
I'm 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 Zenity.
A year and a half ago, we were focused on low-code, no-code security.
That's how we got to observe this space.
And this entire research is going to be featuring research from RealZilber.
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 what we're going to do.
And that's why we're giving this talk.
Here's what we're going to 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 wild on low-code platforms.
We'll start with living off 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 yourself?
How do you manage persistency through low-code platforms?
And then we'll go to predictable misconfigurations and how those are abused outside in scanning.
We'll finish off with two things.
One is you'll have a couple more tools in your relative 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 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, then that automation.
For example, every time I have a job.
Every time I get an email with an attachment, store that attachment in Google Drive.
Applications like handling receipts or onboarding and offboarding users.
There's really lots and lots of business cases for this 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 by definition has access to business data or powers business processes because that's what it's meant for.
And it runs as SaaS, which is important because all of the controls that you're used to, well, they're not there.
This runs on the vendor's cloud.
So, on Microsoft's cloud, on Salesforce's cloud.
And the last piece is that this is vastly underrated by IT and security teams.
So, people.
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 all 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 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 going to be a very quick example.
And let me play while I explain.
Basically, this is a very simple automation.
It's going to 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.
Everybody is seeing.
So, this automation, every time that somebody mentions me, it changes my status as if I'm on a call.
Then the 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 going to 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 O of 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.
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 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 you can, 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 operations.
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 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 we 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, the 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 are able to log into their SaaS.
They can very easily escalate their privileges.
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 that SharePoint.
With the comfortably provided encryption function within Power Automate.
Microsoft's platform.
So, again, ransomware here is just really, 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 export the 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.
These are 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 with other.
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 drop box.
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 overshared 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 shell.
From 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.
Very quickly.
You'll see that tool is 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 shell 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 local 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 very.
There's a much lower bar.
To create these applications.
And there's also another crucial piece here.
This is all run on the vendors.
SaaS products.
So for example.
In the example that I'm going to show you.
It's about PowerPlus.
Or Microsoft's local platform.
The application will end up in a Microsoft.com domain.
So users will trust it.
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.
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.
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.
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 it'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 I've been pwned.
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 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 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.
To remove this window.
Note that if I'm able to do that.
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.
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 living 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.
Ransomware account takeover.
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.
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 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.
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 e-discovery.
To go out and find secrets.
And find business data.
In email.
In Outlook.
In SharePoint.
And then just send it off to a random endpoint.
And nobody was looking for it.
It 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 a schedule.
I'm going to go through all of the files.
In a single SharePoint site.
I'm going to encrypt them.
Send them over to a random endpoint.
For example Pastebin.
And I'm going to tweet about it.
Because why not.
Nobody will find me anyway.
I'm going to 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 the.
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 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 that HTTP endpoint.
Comes built in with a secret.
So we don't 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 all the 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 an endpoint.
You can call it from wherever.
They're not blocking anything like that.
So just go ahead.
And in terms of logs.
Not really.
We're kind of in a problem here.
Because those automations.
Generate a ton of logs.
So I'm talking about every single.
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 going to 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.
Still no arbitrary payloads.
And I really haven't touched the log thing.
So let's see.
How both of these things.
Can get solved.
And for that.
I'm going to use a very.
Useful piece of.
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.
And so.
I'm sure you'll see.
Where I'm going with this.
But I'm going to.
I'm going to take you through it anyways.
Here's.
Here's what we're going to do.
So I'm going to show you.
Exactly how I cover both.
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.
Here's how it works.
I have a single endpoint.
And instead of running.
A specific payload.
It's running a payload.
That's 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.
There are three different things.
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.
The general payload.
So I can just run whatever I want now.
The.
Sorry.
One more thing that we need to.
One more thing that's.
That's covered here.
I haven't actually specifically described it.
Is because.
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 no logs behind.
So the only logs that are left.
Are the fact that this flow.
Is running.
And this can be hidden.
So I'm saying okay.
This flow.
Don't remember anything about it.
Here's the entire flow.
The entire automation.
So again.
One HTTP end point.
Three main commands.
Create an automation.
And trigger it.
Get connections.
So I can create new automations.
With that new connection.
And deleting the automation.
Here's the same thing.
With Microsoft.
So this is kind of small.
So let me make sure that you understand.
What's going on here.
I plug in the webhook.
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.
Basically once you have access.
To power platform.
You follow a small guide.
That I have there.
That's about installing that backdoor.
That's basically uploading something.
Uploading that automation.
That you just see here.
And you get in response the webhook.
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.
Actually 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 living off the land of low code.
To create their own.
To run their own.
Malicious operations.
Based on the local platforms themselves.
We've seen how you can stay within these local platforms.
Remain persistent.
So the first 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 S3 buckets.
So the default was insecure.
Every new bucket was public.
And then even though.
They changed the default.
We're still finding these public.
S3 buckets today.
And so the same thing applies here.
But the key difference.
Is that these are not only developers.
That are building this.
But also business users.
So there's a lot more of it.
We'll see a couple of examples.
The first example.
Is Microsoft's power pages.
Which is basically a website.
That allows you to.
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 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.
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.
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 the entity form set.
Which is basically the way to store.
Form submissions.
So again not really interesting.
But the third part.
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 it easy to find?
Because it's all in the same subdomain.
So every one of those applications.
Is in this subdomain.
And the end point.
The API end point.
Is always the same as well.
So of course we can do kind of 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.
Kind of solve this issue.
Here are the examples.
So lots of.
Nice.
Lots of PII.
Secrets.
API keys.
Authentication tokens.
And lots of business data.
So PDFs.
Pictures of recipes.
So a whole bunch of business data.
So again.
This was a case.
Where there's a misconfiguration.
That is very predictable.
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.
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.
The secret equals 12345.
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.
A lot of them are API keys.
Email.
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.
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.
We understand 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 our hackers are taking advantage of it.
Really kind of all around.
So living 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 low code 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.
There are two things.
And actually.
We've also seen two tools.
That we've released today.
One is for Zapier.
That allows you to find those connections.
Those shared connections.
And the other is the back door.
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.
Here are specific things.
That I really recommend you do quickly.
The first thing.
Is that you need to review configuration.
For example.
The bypass consent flag from Microsoft.
Make sure that's off.
There's 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.
Those external endpoints.
Those platforms are creating for you.
So again.
You don't have to be fully aware of it.
The platforms are exposing the endpoints for you.
And you're not really.
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 dedicated to low code, no code.
That would help you figure out.
What are the different risks that are around this space.
And there's a whole bunch of articles there.
That could help you.
So thank you everyone.
Thank you very much for your time.
It's been fun.