Hi everyone.
Well, let's start my talk.
The title is U.S.
C1 Shuffle, Lateral Movements and Other Creative Steps that Attackers Take in AWS Cloud Environments and How to Detect Them.
So, who am I?
Well, my name is Felipe Esposito.
I'm also known as Proteus.
And a little bit more than 10 years of experience in IT security, mostly on researching and sysadmin stuff.
I'm also a proud father of a girl.
I'm also a booting instructor.
And my main job right now, I'm a security researcher at AT&T Security.
And as a researcher, most of my job is Googling around, reading documentations and creating bugs and testing security stuff.
But sometimes, we are asked to help our clients with some questions they have.
And I remember that day when I was reading docs, Googling around, and one of our clients asked us, hey, can you take a look on these network diagrams and his IAM profiles?
And we said yes.
And he was doing all kinds of nasty stuff.
He was doing stuff like VPC peering between projects in the environment.
He has cross accounts roles between almost all their accounts.
And I said, well, no.
You can't do like this because there's a thing called lateral movements.
And an attacker can take advantage of it.
And he was like, what?
Yeah.
So I made this statement.
I know it's a bold statement.
But I have support.
I have arguments to support this.
So cloud security is more complex than on-premise security.
So by the title of this talk, I was looking for titles who might be lateral movements.
And the only thing that I could remember that moves laterally is Caranguejo or CREBs in English.
And I was like, not a good title for this talk.
But my boss, Ciera, he remembered this kind of dance he's calling Texas Shuffle.
And it looks a little bit more like this.
Seems fun, right?
So as I'm a Brazilian, and I'm also from Rio de Janeiro, I had to bring up something different just to make a contrast between the Texas Shuffle and any other kind of dancing style.
So I brought you what we call Brazilian funky.
And it's something like this.
Yeah.
Seems hard, huh?
So well, let's jump to cloud.
But take those two dances in perspective.
So when we talk about lateral movements on AWS, we can say things about like an attacker can move laterally between an instance on a VPC on account A and a VPC in account B.
If they have a VPC peer established between each other, you know, routes and everything.
And this is what we call the data plane.
And if you take this into consideration, the data plane seems like on-premises network, because we have networks, some networks, house between those networks.
And the attacker can also move laterally between those networks on the data plane and also on-premises networks.
But in cloud, we do have one thing that we call the control plane.
And the control plane is basically how the AWS or other cloud providers control the data plane.
So the control plane basically is all the APIs that we call for creating resources, deleting resources, changing properties on those resources, and things like that.
So in also the control plane, that's where we have the IAM.
And that's the thing that controls permissions on AWS.
So what happens is you can have a role on the control plane, and you can assume another role on the same account.
So if you have an account moderator, you can assume a role administrator on this account.
And this is kind of a lateral movement.
But we can also assume, we can also exact something on the EC2 instance that is on the same account.
So you are in the control plane, and then you can jump to the data plane by executing a command on an EC2 instance in this VPC.
But if that EC2 instance also has a role, you can also jump from between the data plane to the control plane by assuming this role.
So things get a bit more complex, right?
And you can also assume a role from the account A to account B.
So you can assume another role in another account.
And you can also assume a role from the EC2 instance on the VPC A on another account, on account B, for example.
And you can also execute any command from this role here on the account B to any instance on account on the VPC B.
So this makes it much more complex to understand lateral movement possibilities, and much more complex to track this kind of lateral movement possibilities.
So I promised my sister-in-law, she's a dancing teacher, that we can't compare dancing styles, but we can compare aspects.
So if you guys remember those two dances, which one of you seems more difficult to learn?
The Brazilian funk is faster for sure, has a lot of fast movements, but he's dancing alone.
And when you get Texas Shuffle, for instance, you have the interaction between the partners.
They have to balance each other to understand where they are in the space.
They have to coordinate this with the rhythm.
And they can also dance alone by themselves, also always looking for the other partner.
So Texas Shuffle has some aspects that are more complex than Brazilian funk.
So in order to illustrate how the attackers can take creative steps, I was wondering what can I bring to you guys, would you remember this?
And then I remember a music, it's called Cupid Shuffle.
It's like to the left, to the left, to the right, to the right, now kick, now kick, now walk it by yourself, walk it by yourself.
Most of you guys might remember this.
So it's like Macarena for Brazilians.
Yeah, so we have some steps that are called to the left, to the left.
And this happens between EC2 instance to EC2 instance in different accounts, for example, if they have VPC peering.
So what happens is that ARP protocol doesn't work as expected on AWS.
So in AWS, the ARP protocol doesn't have the broadcast.
So there's no easy way to find what are the other networks that you have on the data plane.
So you have to go to the default mode that's scanning.
So yeah, you can use an Nmap for scanning this.
So you can scan a range slash eight.
It's nice, but it's effective.
And you can use this comment right here to do it.
And once you find another machine, after that, you can hack your way into this new instance and then jump in between EC2 instance, also between accounts.
There's another movement that are called step up and diagonal.
That happens when you have an EC2 instance or a Lambda or ECS or a batch job, et cetera, anything that can run any kind of
a program .
And that it has a role to assume.
So there's also a Maitreya tactics for this.
The technique is called 1550.001.
And if the attacker lands for somehow an exploit or any vulnerability on an EC2 instance that has a role to it, he can assume a role and jump from the data plane to the control plane.
So for this, so the attacker lands here, he can get a STS get caller identity to find out each role he has.
And then he can just use the service that's called instance metadata.
He's a service in AWS who allows him to get credentials, find out each IP address he has and do a lot of stuff, finding the host name and things like that.
So with the service, he would be able to get the credentials as we saw right here.
And with those credentials, he can jump to the data to the control plane.
And by jumping to the control plane, he would be able to use tools like Paku.
If you guys don't know Paku, it's like the meta exploit for AWS.
So it's open source AWS exploitation framework.
Pretty good.
And it was developed by the guys of Rhino Security, especially by the late Spencer Gittin.
So it's a great tool if you have AWS credentials to explore and to get doing more nasty stuff on the AWS.
So another letter of movement, I call it step down.
And that happens if any user with any user or role with SSCM or instance, creating instance actions and actions are kind of permissions on AWS, they can execute code and jump to the data plane.
So if you have a user, A, who wants to jump to a specific VPC or a specific subnetwork, and this user has the ability to execute anything, like create, execute an instance that already exists on this VPC.
Or if he can also, if he can create an instance, he could create an instance on this VPC, execute code, and then jump from the control plane to the data plane.
So this is a comment that an attacker would do to make an EC2 instance create a reverse shell for his IP address.
So he's doing an AWS run shell script with these parameters.
And this is what the EC2 instance will exec.
So another movement that I call here, called to the right, to the right.
And that is when you can assume a role between accounts and cross accounts between AWS.
So if you have an account A, you can do an account B has this policy, that means that any principal on account A can assume a role in account B.
So if you have, you can assume a role from account A to account B, right?
But if you are in account B, after assumed a role in it from account A, and you want to assume a role in account C, just jumping between accounts, you might think that's the necessary thing to do is, it's have this policy in account C, like any entity from account B can assume a role in account C.
But the thing is, that's not true.
Because when it comes from account A, an attacker can assume the role in account B, he's not an instance of account B, he's an instance of account A.
So this is not possible.
The only thing that would be possible from assuming a role from B to C, would be a policy like this.
So anything on B, we've assumed the role, and the name of the role, and the value.
Because when you assume a role, you do a temporary value for this, like a comment for this assumed role.
And this might also be true.
But these kind of things, just to be honest with you guys, I never saw in production in any of our clients.
So I don't believe it's feasible to find any other environment with this kind of assumed role, right?
So this won't work for most of the things.
But one thing that one attacker can do is jumping from the account B to a data plane, and then assuming a role in account C.
But this thing here, what we call assume a role for account A, and assume a role for account C, it's called role chaining for AWS.
And it also has a hard limit of one hour.
So one hour might not seem a lot, but when we're talking about control plane, the things that has a lot of APIs, really well documented from AWS, you can just script your attack, and one hour is enough time to run any kind of scripts.
But yeah, this thing has a hard limit to one hour.
But there is a bypass for that, that I call now kick and now kick.
And that's an error when you have account A with assumed role in account B.
And the account B, account C, has assumed role from account B.
What an attacker can do is jump from the control plane to the data plane, gives the EC2 instance the privilege to assume role, and as this EC2 instance is an entity from account B, this policy in account C will work.
And by doing this kind of movement, simplified here, the attacker can bypass this hard limit of one hour, because EC2 instances, are not treated as the same way the other instances are treated for assumed role operations.
So this is well documented here.
And this bypass can work up to 12 hours.
So what are the attacker requirements to do things like this?
It has to have enough privileges.
For example, it has to assume role in resource star.
He also must know a related account ID.
And for finding this related account ID, he can find this in CloudTrail, IAM policies, and also through OSINT.
And they also need to know the origin of a role to assume the new account.
So it can be brute force, or if he came from the master account, if the account has a SSO single-site organizations, and if he came from the master, he'd be able to find another account pretty easily.
So to have enough permissions, there's also a thing that we call AWS privilege escalations.
And privilege escalations are basically a set of actions that allows you as a principal to increase their privileges.
So there was a great research by the late Spencer Gittin, also from the Greenhouse Security Labs.
He found out around 28 no-privilege escalation techniques.
And there will be a new one just released by Spooker Labs in his talk called Village.
Watch it, don't miss it.
And even more possibilities with the IAM pass role.
And there is a research by Nolan Daham, where he's looking for IAM pass role possibilities and how to privilege escalation with that.
But the thing is, privilege escalation is a thing in AWS, and that's not pretty easy to find out and understand those things.
But not all privilege escalations are created equal, because not all techniques have the same effectiveness.
And how so?
So we have here two techniques.
One is called create policy version.
And if an attacker got credentials, and he has not all actions on AWS, but he has a great policy version, he can create a new policy version for him with the system administrator permissions.
And then he becomes a system administration on that AWS account.
But there's another technique that's called IAM set default policy version.
That means that the attacker has the version v1 right now on his, and he has this privilege set default policy version.
But to become a system administrator, he needs that the previous version, or any of the previously versions, has the system administrator possibility.
So he has a precondition to privilege escalate in this technique.
So how do we find out possibilities of privilege escalation?
There is a tool, there is called CloudExplaining, and was created by Ken McQuaid, was first released on 30 April of 2020.
And this is a IAM security assessment tool.
This tool is able to create, to find out privilege escalation possibilities in customer policies, inline policies on AWS, and also find out about data filtration possibilities, resource exposure, credential exposure, and infrastructure modification.
So this tool is really great.
And if you didn't know, you can use it to find out possibilities of privilege escalations in your environment, right?
So any other, what are the requirements that an attacker would need to move laterally between AWS accounts, would be an ID of the related account.
So it can be found in CloudTrail, IAM policies, and also SYNT.
And you can also, for example, you know, SYNT stuff, you can find out the company GitHub, find Terraform scripts, and other kind of things.
And those numbers might be, or might not be, but they are probably hard-coded on those files, right?
So in this, we have an example of CloudTrail, and we can find out there's account ID doing anything here with the account ID, and you can find out the account IDs also from the CloudTrail.
So if the attackers also use AWS organizations or Control Tower, the attacker also, he needs to know a role to assume on these accounts.
So he's in account A, he wants to assume a role in account B, but he also knows a role, he has to know a name, the ID of the account, and he has to know the name of the role to assume.
But if the organizations use AWS, if the AWS accounts use organizations or Control Tower, the attacker knows the name of those roles because they are hard-coded.
So if the attacker gets access to the master account, it's game over, it's final dance, because from the master, the attacker with the assumed role condition can assume any role, can assume a role called organizational account access role, or he can also assume a role called AWS Control Tower execution.
And those roles, by default, they have admin privileges in all the accounts with the same organizations.
So protect your master account as much as possible.
If useful, if it's used, well, do not use any kind of workload on the master accounts.
So there are some scenarios, our best practice from AWS that we can explore to understand ladder movements possibilities.
So the first scenario is called Rub and Spoke.
This is a really well understood network design from AWS.
So we have several accounts, accounts A, accounts B, accounts C, a shared services account.
And what you can do, the wrong things that you can do is create an EC2 instance with two network interfaces on the shared services.
And those interfaces connect to the account A to the account C.
So it might be a route point.
So an attacker who got an account A, he can hack this instance, and then jump to account C.
But you can also do you can also do a VPC peering between account A, account B and account C.
This also might break the network interface that want to work on this network.
So don't do it.
Please don't do it.
Right.
And another AWS pattern and possible thing that you can do is to cross back, cross account back to master all CICD accounts.
So this we have a partner, a pattern that we call, and the user logins to the master account.
And this user, he has access to CICD.
And he has access also to dev and to staging, but he doesn't have access to prod.
Right.
But what happens if the administrator of this account do a cross account between the dev and CICD?
This user, as an attacker, he can just do a cross account to the master and just jump to the dev.
He can also jump to the dev.
But the CICD account, as he has permissions to deploy in prod, he can also make a jump to prod.
So also do not never cross accounts between your dev environments and staging environments back to a master or CICD account.
So in order to find out in our clients, we tested a lot of tools, but none of did what we wanted to do.
We test AWS PX.
We tested CloudMapper from dual labs.
We tested several tools, but none of them was able to deliver what we were thinking about.
What we thought that would be a good delivery to find out a lot of movements.
So we have to create your own.
So we had some requirements for that.
One of our requirements is to use open source and free tools, automatically download the necessary information from the AWS APIs, plot an easy to understand graph with graphs, what an attacker could do at a control plane data plane as well, and has a carry language to allow alerts to be raised automatically.
So as a backend, use Gremlin as a carry language.
We also use Cloud Splane to download all the information, not all the information, but some information automatically, and also understand what previous collision techniques would be useful.
And we also use D3.js for visualization.
So what we model, we model things like if anything is to instance or a lambda, anything from data plane is a square.
Anything from the control plane is a circle.
Anything that has, if it has the same account, AWS account, it has the same color, different colors, different accounts.
And we also model a row and arrow, and that's a directional relationship between any of those instances, right?
So kind of demo time.
Well, the name has no name.
The tool has no name yet.
So there was, back on the Cloud Village, there was a pool on Twitter to find out the name of this tool.
We are in some days to release this tool, so keep up, keep looking for our Twitter accounts, and we'll be released soon, right?
So for the demo time,
as I said, the tool has no name yet.
And by clicking search, it downloads all the information and plot the graphs, and you can also zoom, you can pan in, pan out, move laterally things.
As you can see, there are several colors here.
And this data, it came from a simulation that one of our clients who has hacked it.
So one of our clients lost his credentials for one of his accounts.
And by the end of the time, the end of the day, the attacker just created an EC2 instance and running some crypto miners on that.
So we were able to catch it pretty quickly and clean up the account.
But what the attacker could do, if he has the visibility of the possibilities that he could do, it's much more scary than just crypto mining.
So just organize, you can move things, you can just organize things here.
The thing is, the attacker lost control of this
account , and he would be able to create an EC2 instance.
This EC2 instance has an assumed role.
He would be able to jump to all other accounts, because this EC2 instance was in a master account.
And he also has a VPC peering.
And if you see, if you watch closely, all the connections between VPCs are two-way connections.
So you have EC2 instance.
We have a connection from this EC2 instance to this EC2 instance, and back and forth.
And he could also jump from this to this EC2 instance, and then also assume a role in this account here.
As you can see, he could assume a role in another account.
He could also jump to this EC2 instance right here, and then become an administrator on this orange account.
One thing that we find out, the easiest way to analyze these things is to look for big clusters like this, because they have the most interactions, like this.
And things like this are just lambdas with assumed roles, and they're not really well connected to the graph.
So by analyzing, the easiest way is to be looking for large clusters.
And you can also have a filter here for privileged escalations, that you could find out that this role here has a privileged escalation possibility to this role, that's the administrator role, by creating a new policy version, as you can see here.
So you can also find out privileged escalation possibilities.
So what's the future or our to-do list for EC2?
We want to evaluate all the restrictions of all privileged escalation techniques, so it just takes a little bit more time.
We also want to support, to add support for other resources like S3 and RDS, and also support for resource-based policies.
And a little bit better visualization and filtering, because there's what this visualization thing was just a POC, a POC, and was using another open source tool, it's called GraphXL, something like this.
But we want to do better with this.
So in order to conclude, what you have to have in mind, so also try to apply the least privilege to IAM role permissions, and this is said and done, we know that.
But you can use SCPs and IAM boundaries, and please, please try to never use a resource star, that brings a lot of possibilities to attackers.
And don't run any workloads in your master account.
So if you run any workloads in a master account, and if you by accident give this workload, EC2 instance, assume role, you can recruit a jump between all those accounts in your environment.
And also don't cross-account any accounts to master, or any accounts to CICD accounts, and things like that.
So always review all your trusted cross-account policies, and segment your network and accounts as much as possible.
So thank you guys, thank you for coming, watching my talk.
Hope to see you guys next year on CloudVillage and DEF CON 31.
So these are my contacts, Twitter, the TTC security Twitter, and my LinkedIn.
So if you have any questions, just keep in touch.
See you!