← All talks

BG - Lateral Movement and other Creative Steps Attackers Take in AWS

BSides Las Vegas36:45261 viewsPublished 2022-09Watch on YouTube ↗
About this talk
BG - The Northern Virginia Shuffle: Lateral Movement and other Creative Steps Attackers Take in AWS Cloud Environments and how to detect them. - Felipe A Pr0teus Breaking Ground @ 14:00 - 14:55 BSidesLV 2022 - Lucky 13 - 08/10/2022
Show transcript [en]

all right hello good afternoon welcome to b-sides Las Vegas you are in breaking ground uh this talk is the north northern Virginia Shuffle lateral movement and other Creative Steps attackers take in AWS Cloud environments and how to detect them let's get started please welcome Philippe proteus [Applause] thank you everybody thank you for coming for my talk so my name is Philippe as you you heard from Pierce and my nickname is proteus so just my mom called Philip so you can Comfort us wherever you find me whenever so a little bit about me I have at least 10 years of experience in Security in general I'm a proud father of a girl and also blue team structure back in Brazil and I'm security researcher at Mt security did you think she's security is a startup company based uh focused in Cloud security and third-party risk management and as a asthma's role as security researcher part of my job is Googling around reading documentations and writing box to test for their abilities and this kind of stuff and sometimes we help our clients with with questions so I I was there one day Googling around reading docs and one of our clients came to us and asking about his Network diagram on AWS and he was doing all kinds of nasty stuff he was doing things like people's appearing between Dev and product environment draws accounts between that and project environments and I said no you're doing something really nasty here you shouldn't doing this because there's the problem of lateral movements and he says what and yeah and then I explain him and then something popped in my mind I just realized that uh Cloud security is more complex than on-premise security and I know that's a bold statement but I do have uh analogy or a metaphor to explain that so by the title of this talk when I submitted this talk to besides I was thinking well what things work laterally and doesn't work watery so I can think get a thing for my talk and the only thing that I could think was scraps but I don't like crabs I guess nobody like crabs so I was talking to my boss Sierra and he told me about this kind of dances it's called Texas Shuffle and for those who doesn't know which Texas Shuffle kind of dancing style is is something like this seems nice right but I'm a Brazilian and I'm from Rio Janeiro actually so I have to bring something for you for you guys to do a contrast between the Texas Shuffle and the dancing that I brought here today is something that we call pasino it's like a Brazilian thing so kind of like this yeah two different dancing styles with their respective differences but and you'll get a little bit more on this later but just keep those dancing in mind so when we talk about lateral movements and possibilities of lateral movements how many of you guys already did a pen test on on-prem's Networks how long did you guys take to get a domain to me more than a day or more than two days usually you just pivot pretty fast between all the networks find the domain to me uh get the credentials and becomes a domain administrator right so this can also be done on AWS but on AWS you can have separate accounts so you can have account a and account to be and for do this kind of things in AWS must have to be a VPC bearing between those accounts and those vpcs right so when an attacker usually attacker doesn't land when he went when they when when their objective is so he has to move laterally right so if he hackets are instance on the vpca he can find out on other networks and move laterally into the vpcb and so on this thing in AWS we call data plane and data plane is where your data lives actually but on cloud we also have another plane that's called the control plane and the control plane is like it's all the apis that you call to make requests to your cloud provider for example in AWS you called it the control plane to create a new VPC to create easy to ministers RS3 buckets or something things like that and the the thing with the data plane to get in you just have to get something exposed like an IP address or things like that but just to get in on the control plane you're gonna need a credential or a login password or AWS access three keys and so on in the control plane you have entities like users rows groups and things like that so how do you move it laterally on the control plane so here you have a row and in account a and this road can assume another road the road to in the same account but the thing is the the attacker who has who got the role well he could also Zack and create an instance on the vpca and then he can jump from the control plane into the data plane and if the attacker gotta is a first hackage aec2 instance and he find out that his institutions has a role attached to it he can assume that role and jump to the control plane and from there he can also find out on other networks and other accounts in AWS and jump from account a to account B and he could also from the same ec2 instance if he find out another account he can jump from the institutions in account a to another role in a in account B so you can think pretty much see that this these things getting even more complex than on-premes Network right and even though uh the same attacker who has a role in account in account TB he can also exec and his due to create an instance on VPC on account to be so really really mess right so just to bring that comparison between those dances and I promise to my sister-in-law do not make comparisons between dances because that's not something that you should do but we can compare features between those dances so who thought that the Brazilian Frank would be more hard to learn uh oh well who thought that the Brazilian Funk would be harder to learn than Texas Shuffle anyway yeah but the thing is the Brazilian fact it's only fast he was dancing by himself fast moves yeah but there's him by himself the Texas Shuffle uh he has to interact that has interaction between the partners so they also can dance by themselves if you watch the the video clip again they also then separated between them but they also have to coordinate their weights and balance between them so there's much more aspects and complexity in Texas Shuffle than Brazilian passing you so the texture Shuffle should be our Cloud environment the comparison between data planning control plane and the balancing between those so uh I created not created actually I just copied from the Cupid Shuffle some steps to introduce you to the lateral movements so everybody knows that musk is that to the left to the left to the right to the right now click now kick now walking by yourself but that's a really Anthem um at least Cruisers and things like that in marriages so when we talk about lateral movements on the data plane uh you between two two easy two instances on different vpcs connected by a VPC peering some things doesn't work as expected for example iarp protocol RP protocol doesn't work as expected because in AWS you don't have the broadcast broadcast so if you enter in consult and do arp-a you won't see any machine just your machine in the router so there is no easy ways for an attacker to find out which other networks are connected to the to this account so the solution for this is to do a network scam so he can scan the whole range the whole slash eight range it's nice but effective it's gonna if you the if the blue team of that company has some flow logs and things like that you're gonna catch him but it's effective for the attacker so he couldn't find a new instance on those and other vpcs and on other sub networks and then hack it their way into this new instance another kind of lateral movement is when the attacker came from the ec2 he hacked the ec2 instance for example and or a Lambda or ECS or a batch job there's any kind of data plane uh things that can assume a role and he can just get those information enter on this machine if there is a role attached to it he can store these credentials and jump into the control plane by doing this something pretty much like this so the attacker lens so this is situ instance so he does a STS get caller identity to find out which hole he has and now you can see that he has the thing she easy to roll so you're going to dump credentials to jump to the control plane by doing this he is working he's using the metadata metadata is a service from AWS who gives a lot of information about the the role that that situ instance has and credentials and informations about that instance so here the attack would be able to get the credentials and then he can use uh some tools to post exploration that one of the tools is the paku it's a open source AWS exploitation framework developed by the Reno security guys so if you guys don't know this tool just download and play around pretty good too has some some defects I don't know how to say that but it's pretty good too in general so there is another kind of lateral movement that are called here step down and that means when when an attacker is able to get any kind of credentials or access keys or uh login password without MFA from a user or perhaps with MFA with phishing uh the attacker get discrimination connects the control plane and if he find out there is a VPC there and he wants to see what else hasn't that he doesn't have enough permissions to walking around that networks well he creates a new ec2 instance then he sends a command for that institution instance for example using the SSM or loading the data inside the user data for that Institute instance and then he can jump to that easy to instance and execute code here in this example the attacker he sends an sscm sent comments to an instance and creating a reverse shell for here attacker IP address on part 31 3037 so and when we talk about lateral movements on the control plane things are a little bit more trickier than on the data plane right so uh here we have three accounts let's assume that we have three accounts accounts a account B and account C if the attacker gets a credential and accounts a and the accounts B has this following policy here that says that the principle is a AWS any entity coming from the account a so a user is an entity from account hey can assume role so an attacker would be able to jump from the account a to the account B without no problem and assume this row but when you think uh an attacker got access to account B and he wants to jump to account C you think you you you're tempting to think that this policy must be enough for him to jump between accounts from account to be to account C but that's not true because when it happens when uh the the attacker assumed the role from accounting a to account to B and then try to assume a role in account C he is not actually coming from the account B it's coming from accounting a and this policy won't work the true pulse that has to work it's something like this it has to be uh assumed role for an account to be with a role and when you assume a rolling account you should you should usually you put a value like a testing or your name your username something like that and it also has to happen here in the policy on our company I would be pretty honest with you guys I've never seen this in any of our clients nothing like that so I suppose not work like this and the thing is that that thing that we call uh assuming role a summary rule on being a Sumo role on C it's called roller chaining and this has a hard limit of one hour from AWS so even though if you could be able to assume around be in a summer role on C uh the maximum time that you can assume that role is for one hour that's not much a big problem because all the apis from the AWS are real real well documented and attacker might script their way and creating persistence in back doors all over so this role chaining is not a big problem but an attacker can be creative right and usually they are so there's another kind of movement that are called now geek because when this policy comes from the accounts B the account B is the root an entity on an account to be right so if your attacker has the action or the ability to create an Institute instance he would be able whatever all right so when they are counting when an attacker in a county would be able to to exact uh create an ec2 instance on the same account the ac2 instance is a entity on this account so he would be able to assume a role give a permission to enter which is a situations to assume a role on account B and he jumps to account to be as an entity assumed by account a but he also could be able to create a new instance on accounts B and then jump to account B and then assume a rolling account receipt and would be something like this so he he went to the control plane down to the data plane back to the control plane down to the data plane and then back to the control plane again until he reached the account seat so that's the curse because AWS doesn't reach a situ instance uh a situations using roles as a rolly chaining thing so there's no limits there's a limit to up to 12 hours but it's a way to bypass that so what are the attacker requirements to make this thing work so it has to have enough privilege on AWS so he must have STS assumed role and preferably resource star that means that he can assume a role in any resource and he also has to know a related accounts on the same organizations so this can be found in cloudtrail I am policing through all things sometimes you go to the GitHub account from that organizations and find out they have like three or four other accounts uh which which account numbers shared there because account numbers are not really a secret right so you you can share it's not supposed to but you can and they also has to know a army of a role to assuming the new account so when you do an SDS assume role you have to know the art that you the irony of the role that you assume in the the new account this can be brute force it because usually it's created by humans so you can reinforce like a role like an account number roll admin administrator and things like that but there's a special case because when it's coming from the master accounts there's a special case for that so let's talk a little bit about privilege escalation privilege escalations a set of actions that allows a principle to increase their privileges for instance uh you can imagine a user with a really low privilege but with enough enough actions to improve his his actions his capabilities theirs was a great research by the late Spencer geitzen from Reno security labs and he found out at least 20 uh 28 no privileged Collision techniques and there's a there was a really new One released by spooker Labs today in his talk if you guys saw it on app stream about that upstream and there is even more possibilities because with combinations with eim pass role there's a this is an action on AWS and there's a really good research by Innova and Dam and when he find out new kind of privileged escalations combining eim pass role and other actions from AWS but the thing is not all privileged collisions are created equal let's take some examples a lot of the techniques have the same effective Effectiveness and allow you to become an administrator ASAP so here we have two techniques the first one is the IIM create pulse version that allows you to become assistant administrator as just creating a new policy version and becoming administrator right but that is the another technique called set default policy version that depends on you have another policy version that allows you to become administrator earlier so if you have the pulse version if you want here that allows you to set the photos version but the pulse version v0 doesn't allows you to become a assistant administrator this this technique of privileged escalation might give you some more permissions the permissions of the version zero but not become a assistant administrator right so there is a tool there's called fault Spain anyone have ever used it yeah it's a good tool it was created by Kinder McQuaid he was working in a sales force at that time and release these two on April 30 2020 and the current version is zero five oh but the good thing about this too is that it downloads your IAM policies online policies custom policies and AWS policies and analyze those policies looking for privileged Collision techniques data filtration possibilities of tactic situations resource exposure credential exposure and infrastructure modification so you generated this kind of reports 3D 3D HTML Report with those texts and it is bar graph bars and things like that so turns out it's pretty easy to analyze privilege correlations with this tool so another attacker requirement is to know the I the account ID of a related account on the same organization right so this can be found on cloudtrail and here we have an example of a cloud straight of uh em role getting AWS API call uh it's closing an account ID and you can also be found in AIM policies because if you have cross account policies and those trust account has to have the number of the accounts uh to the destination right so you can find out new numbers there and also through of things uh as the example of the GitHub that I gave you guys before so and the the third thing and the third trick actually if the targets use AWS organizations or awsc Contour Tower uh the role that organization that AWS organization creates and control tower creates on the the child accounts on AWS it's a well-known name it's called organizational cards access roles and for the control tower is at AWS control tower execution and they have admin privileges in their child accounts by default so if an attacker gets access to the master account you will know by just doing our organization list the number of the the number of the accounts he has and he can also jump from his account from their Master accounts to any other accounts because he already know the rules for that like organization access or AWS control tower even though the AWS control tower is efficient role has two principles one is defined the services so control tower can also assume a role on on your account but the the thing is there is a principle here from the master account as any entity on the master account can also assume this role so you if an attacker got access to a master account it's done game over so let's run some some true scenarios on AWS some usually patterns that people do on AWS so the first button is called Hub and spoke when you have a multiple accounts which accounts for a production account for a development staging and so on and a shared account who shares like database and things like that so as a AWS administrator you can do some kind of mistakes for example for example creating IAC to instance on the shared VPC uh with the two Enis one were routing to account a and another one routing to accountancy what that means that means that if an attacker could hack any accounting act in any situ instance in account a find out there is an instance on on the shared vpcs have the shared vpcs here you will see that you have two NIS and then another one will allow you to allow him to jump to account C and the other things that you can do on this kind of scenario is do DPC peering so if you do VPC printing between account a to account B to account C you are basically making your network flat and there is another pattern there called cicd account it's like basically like this you have a master account and you have your cicg account and this ICD do deploy for that for stage infrastruct accounts and the master can access the dev and the stage a user in a master can access the depth and stage but he can use usually access their products account what our administrator can do to break this pattern is create a cross account between the dev and the cicd the backwards you see and when he do that the user might be able to get a credential and have then jump to cicd and then jump to