Six Hundred Degrees of IAM Admin: Battles with a Cloud Conscious Adversary

Happy to talk to you today. So my session today is going to be about cloud attacks, adversaries in the cloud. I'll discuss both categories of attackers who are targeting cloud workloads, human attackers as well as agentic attackers. I'll talk about the control plane in the cloud. Why the control plane is a target. Then we'll talk about identity and access management centric exploits. We'll look at attack pathways in the cloud. And then we'll look at defensive strategies and what can we do to try to countermeasure these exploits. So from the control plane exploit perspective. So as we know in the cloud environment there are two types of planes. There's a data plane and there is a control plane. So a lot of the

attacks that are being reported are where the attackers are specifically targeting the control plane. So the control plane serves as a central governance layer. So this is the one provided by the cloud service provider. Any of the infrastructure as a service platforms provide the control plane. And what what the attackers are doing as far as control plane exploits are concerned is that if you look at the data plane, the data plane has resources for the cloud workload. Each tenant in the cloud has a different set of data plane resources. So for example, one organization might have a set of compute instances in their tenant. A different organization might have storage buckets. So it's not going to be consistent. But

if you look at the control plane, the actual fabric that's serving these resources, the ability to provision a resource, the ability to shut it down, these primitives are consistent across every tenant in the cloud. So what the thread actor can do is to create their own tenant in the cloud. In that tenant, they can disable all security controls. So effectively there is no monitoring going on. And then they can take their time and perfect an attacker playbook that goes after the primitives exposed by the control plane. Once they do that, so once they know that these exploit techniques will work against the control plane, they can repeat that against every other tenant which they are really

trying to target the actual organization that they are going after. That can be repeated and they know it'll work because the control plane is the same across every tenant unlike the data plane. So that's why attackers are actually trying to target the control plane. So that's a very important point. Attackers in the cloud no longer need to use malware and bring in any malware binaries into offensive playbook because if you go after the control plane you will succeed. So let's look at a attack life cycle of an actual attack that goes on where the threat actor is a human attacker going after the cloud control plane and using identity exploits. So here is an attack killchain. So the

attacker goes and looks for a S3 bucket and on the S3 bucket they find a set of SSH keys. These SSH keys allow the attacker to get in into the SSH server. They land on the SSH server. Then on the server's file system, they find credentials for AWS credentials for getting CLI access to a cloud workload. So once they have the C credentials they are then able to go and use those credentials to get access to a organization's tenant and then they use the CLI to perform additional discovery commands eventually elevate permissions find interesting data and exfiltrate it. So if you look at this attack life cycle, there's no malware being brought in and there's really no problem as far as

organization security controls are concerned. There is a some amount of misconfiguration in the fact that the credentials were leaked on the storage bucket, but that's about it. everything else is looking consistent with regular cloud security best practices and still the attacker can go and actually do this and they can go after the AM service and target the control plane get access to the data and excfiltrate it. So that's one example. Now let's look at a a more recent example about what attackers are doing from an AI infrastructure perspective. So a recent research report published by cyig about a couple of weeks back was a this is actual exploit that occurred against an cloud environment where the

attacker performed what is called as LLM jacking and LLM jacking is effectively a exploit where the attacker is trying to launch foundation models in AWS bedrock in an unauthorized manner. So they get access to GPU and they can use it to train their machine learning models and get access to a ton of actual uh free GPU capability. Now the question is how did the attacker get access to the bedrock instance and how were they able to complete their LLM jacking exploit. So in this exploit sequence the attacker started by looking at again a S3 bucket. On the S3 bucket they found access to valid AWS credentials. So that's the first step. Initial access is ex is

found by getting access to valid credentials. After that the attacker then once they have initial access they perform some enumeration looking for AM roles which are effectively non-human identities and these are as we know they are required to provision any compute instance in the cloud and so attackers know that these identities will exist so they perform some enumeration in this case that enumeration was performed completely by an LLM and they look for specific roles with certain nomenclatures so they were looking for roles that were named as net admin or admin. So they had specific criteria when they were doing the enumeration not doing brute force. Once they find these type of roles with the relevant

permissions, then they actually go and use those roles to elevate permissions. Once they get elevated permissions, they found a lambda function. they were able to go and replace the code in the lambda function through code injection exploits and then use that as a persistence backd dooror eventually get access to uh bedrock instance and then launch their own foundation models. So this is a multi-step exploit killch chain. But the interesting part here is the entire life cycle of the multiple steps was completed in about 2 hours. And the steps where the attacker got access to privileges in the cloud getting access to admin in the cloud was done in only 8 minutes. Okay. And that's because the

entire exploit life cycle after the initial access was automated using AI. And so the exploit sequence was done by an agent without requiring any human interaction whatsoever. So there's no malware. There's not even a human in the loop anymore. And so these things are what is actually occurring in cloud environments today. So now if you look at any cloud exploit ultimately assuming the threat actor who has got in is not already a privileged identity then one of the things they need to do is to elevate permissions because once you have admin permissions then you can get get access to trusted resources you can get access to data. So the question for the thread thread actor

is one of their objectives early in their kill chain is to be able to escalate privileges. So now the question is how is the attacker going to do it? Unfortunately for the defender there are many different ways to do that as far as a threat actor is concerned. So here is a list for example from AWS which catalogs a set of possible techniques that are used for privilege escalation in the cloud. So there are many different permissions against every different service which can be used by attackers to go and exploit these permissions and elevate their permissions. Now because of the fine grain nature of the cloud-based arbback model ultimately cloud environments in order to run your business in the cloud

you have to grant some of these permissions to some of your resources in the cloud. There's no way to not grant those permissions otherwise you cannot actually run a cloud workload. So fundamentally the defender's challenge is that these are necessary things and you have to be able to grant these permissions. However, the attacker's advantage is that they have not one, they have a multitude of options and any of these permissions can be used by the attacker to actually go and abuse the cloud workload and elevate permissions. So, this is making it difficult for the defender. So now let's look at attacker pathways. So if the goal of the attacker is to be able to elevate permissions, the

question is what are the steps that the attacker needs to do in order to do that? So there is this concept of attack paths and many of us might have uh been aware of the original talk by Spectre ops or blood hound authors called six degrees of domain admin which they did at besides Las Vegas several years ago and that talk has now a new chapter done by again blood hound authors when they introduced what is called as Azure hound which is actually going after the cloud workloads and that talk was titled six degrees of global admin where effectively what they are trying to do is to say you can use open-source tools like bloodounds derivative as your round

and it will do attack path planning for the attacker. So what this does as an output is it shows the attacker that from your initial beach head if you do the following steps as part of the attack kill chain then you will get to your objective. The objective might be a privileged identity. The objective might be an important resource. But ultimately the attacker has a pathway and there are many different pathways at the disposal of the attacker. And these tools are freely available in the open-source world with AI available to the attacker. AI can analyze these attack pathways and go after many different pathways after every killchain. So that's the the challenge that there are so many

different options for the attacker and agents can automate the traversal of these pathways. So if that's the the state of the world from a threat point of view, now let's pivot and look at the defenders perspective. So if you if to summarize what we discussed on the attacker attacker side is attackers are going after the control plane in the cloud. They're using existing permissions. They're not bringing in malware and they are automating their exploit sequence using agentic exploits. So this is basically the summary of the threat landscape on the cloud side. Now let's look at the defenders point of view and see what can we do as defenders to be able to deal with this. Traditional

solutions trying to find malware are no longer going to work because there is no malware being used in this exploitical chain at all. So then the question is the defendant needs to have a approach which has to look at the problem from a holistic perspective. So as cyber security professionals we know that there is no one layer that can actually solve all the problems. So there is no silver bullet in security because the attacker as we look at especially from the offensive kill chain point of view there are so many different options for the attacker and many different pathways. So as a defender one knows that you cannot have a single layer. So you need to combine layers in the

concept of what is called as layered defense. And the layered defense concept is based on prevention as well as detection controls. Now from a prevention point of view, the whole idea is to be able to try to reduce permissions, grant the least privileges that are possible. So that way you reduce the exploitable attack surface to the extent that one can control. But then as a defender it's also important to recognize if as we looked at the threat landscape that there will be an exploitable attack surface available to the attacker like the permissions that we saw for escalating privileges will always exist. So one needs detection controls and now the defender's point of view has to be you have to pick your

layers carefully because each layer in cyber security can sometimes be overlapping. So if they're overlapping they can have similar gaps and so you have to pick layers that are complementaryary to each other. That way you avoid having the same gaps across these layers because if there are the similar gaps the attacker will drive through those gaps and get to their mission no matter how many controls you put in place. So there has to be some strategy around picking your layers carefully and then setting the defensive approach. So let's look at what can we do in that area. So from a threat detection point of view, detection in the cloud is pretty challenging because from a defender

perspective, there are multiple unique characteristics of the cloud that make detection challenging. One of the things is the cloud workload tends to be ephemeral and shortlived. So for example, there are containers running in the cloud. Many of these containers might run for a couple of minutes. And if your detection approach is based on anomaly or baselining, the thing is it takes time to build a baseline and then find a deviation from the baseline. So if your workload itself is ephemeral and transient, then how are you actually going to establish a baseline and find a deviation? It's very hard to do that in a practical sense. So fundamentally many times finding a deviation becomes difficult. So then the other options are

about looking at the logs and trying to analyze the logs to try to find a pattern indicating malicious activity. This is a relevant approach and should be used. The challenge again for the defender is if you look at the cloud workloads there is a control plane log. For example in AWS there is cloud trail but the data plane also has its own logs and there is more than one source of these logs. So for example, EC2 has access logs. S3 has its own access logs and there is no correlation identifier that ties these logs together. So there is no session ID to say here is what the attacker did and I'll trace these various logs and I will match them. So

finding malicious activity by purely analyzing the logs becomes difficult in practice. So so effectively defenders need to find a way to make this work given the current threat landscape. So now let's look at what can a defender do. And so the main idea is if the defender applies the attacker's mindset. So if you think like your adversary and say okay this is what the attacker is doing. They're not bringing malware. They're going to go after identities. They're going to elevate permissions and they're going to go after high value assets in the cloud. If you know those things ahead of time then can you formulate your defensive strategy accordingly. So for that's certainly a possibility and the various best

practices and learnings in this area are around these types. So the first part is that one should use detection engineering rules to actually set particular patterns for known attacker TTPs. So one knows that there are a set of known threats. For example, the permissions that we saw for elevating privileges earlier in the discussion. One can write rules to say if I see these permissions being called unreasonable number of times then I can raise some form of an alert because I know as a defender that these are associated with privilege escalation. So I have a suspicion that if this occurs it could be malicious. So one can write rules looking for those occurrence of those permissions. The other thing one

can do is to look for known type of attacker tools. So if there are any attacker tools being brought in not necessarily malware but any tools to automate these exploits like an agentic tool one can look for traces in the logs of those tools and then build rules based on that. So if you do that you can reduce your exploitable attack surface by a fairly good margin. Now comes the next innovative and important concept here. What we are trying to do is to say can we as defenders so if we can we turn around the attacker and play their game back against them and can we win against this type of a attack kill chain. So what if

instead of if the attacker is having six degrees of admin, what if the defender does 600° of admin, okay, where the defender says I have the first boomer advantage. Okay, so we know as defenders that we are going in first into a environment, we control the resources. We know in the cloud where the high value assets are. So we know that in these accounts in our AWS workload, I have privileged database instances. I have AWS bedrock deployed in this particular AWS account. You know that ahead of time and you know that as a defender that the attacker is going to go after it whether it's today or it's tomorrow. So you have the home field

advantage of knowing your resources, you know your high value assets and you know that that's what is going to be the target. So if if you know that ahead of time then the question is can you do something about it given that knowledge. So one approach here is to say can we as defenders have access to the same attack path planning tools that the attacker has for example as your hound is available for defenders as well and defenders are using it today. So if we can do the attack path planning ahead of time as defenders and we can say okay here are the set of steps that the attacker is likely to take. We don't

know which of them they will take but we know the universe of possibilities. So we say here are the set of possible combinations that the attacker will use. Then we can go and say if there are let's say about 50 different options for the attacker in terms of attack paths. Let's create a set of traps which are fake uh resources along the way. So you can create deceptions, honey tokens, decoys that can represent fake identities, fake resources. And for the attacker it will look like those 50 paths are now got multiplied to 200 paths because attacker doesn't have perfect information. So they need to go and find out what are the set of pathways and we can send them down a

rabbit hole and waste their time and resources. And that can be a elegant way to be able to slow down the attacker, divert them and then give time to the defender to be able to respond and shut off the attacker. So here is a interesting report done by the University of Bengurion in in Israel which is a recent report about attacks cloaks and daggers and these are this is a research paper which talks about how one can use honey tokens and deception to be able to compensate for LLM based exploits. So this paper can be read offline whenever you have time. It it has very interesting uh research and academic backing on the setting traps for agents

to send the agents down a diversionary pathway. Now the question is if that's the your technique to be able to divert the attacker and then the agent the question is what type of traps would make sense. So for that the MITER attack framework is a good basis to set your defensive strategy. So as we know as MITER ultimately they have cataloged the universe of exploits and they have created a set of tactics and techniques. In the last version of the MITER attack framework there were about 14 tactics that are the highle tactics of what the attacker can do. Some of these tactics are associated with early in the attack life cycle activity like for example

reconnaissance looking for credentials lateral movement. These occur earlier in the kill chain compared to late stage activity like exfiltration or impact. And so as a defender, one knows that you're running against a clock. The attacker is going to get access to privileges within 8 minutes. And so you need to do something. You have only 8 minutes to go and combat an agentic attacker. And so the question is what can you do within those 8 minutes? So we can as defenders say if we set traps the ones in the orange here in the diagram are the tactics associated with early kill chain activity. So as defenders we can set traps for the early in the killchain activityated

traps and we know that the attacker will go through these life cycle and so as soon as they go we will detect divert and then protect the assets. So let's look at a actual example of how this will occur in a in a environment. So I'll play out this uh uh video in a second if okay so here is a case where the attacker has got access to a uh instance cloud instance and they are not having privileges in the cloud okay so they're trying to elevate permissions that's the goal of the attacker and in order to do that they're going to go through a set of steps so the attacker is doing an enumeration looking for privileged IM

roles And this is like what the agentic attack did. So they do this enumeration, they find a set of interesting roles. They're looking for roles with certain names and patterns. They find a role. Then they do the deeper reconnaissance to find the permissions associated with the role because attacker always is worried that the defender can catch them. So they're going to look for permissions to say, can I find a role that has permissions associated with privilege escalation opportunities? those permissions that we saw earlier in the discussion. So the attacker is now going ahead and doing the reconnaissance deeper reconnaissance looking for the permissions. So they find the permissions associated with the role and here these are the permissions

that the attacker sees and these permissions the attacker will use to be able to elevate privileges. For example, this role has a permission to start and stop a database. So the attacker knows that I I have access to a role that has these permissions and if I just go after this role I should be able to exploit it. So if one as a defender if we did not have any traps set for the attacker they would have gone after this role and they would have been able to go and create damage for the environment. So now let's see what we can do as a defender. So this role can be a trap that we can set for the attacker and so

effectively okay sorry for the the video of this. Okay so the sorry so the attacker is now attempting to assume the role but this role is actually a trap. It's a honey token set for the attacker. So the attacker went after that rabbit hole but it was a diversion and that's a fake role that the defender created. And if the attacker went after it, the defender gets an alert and one can actually save time and get bandwidth back for the defender. So that gives you an example of what one can do to be able to solve this problem. Uh any questions? Ah very good question. That's very good question. Uh service control policies SCPs can be used to deny role assumption

because it's a dual-edged sword. The the idea is that you're granting permissions. You have to make the role interesting otherwise attacker will not go after it. So you also want to make sure that that does not create harm for the organization. So one needs to be able to have a concept of containment and containment can be done through SCPs. Yes. Sorry. So the he's saying uh is there a list or of all the known paths that the attacker can abuse in a cloud environment. So the there are certain things that are known ahead of time. For example, the set of techniques are cataloged by MITER. So to elevate permissions. So some are known ahead of

time but others are specific to the given tenant. And so for those that are tenant specific, one can run the attacker tools as a defender. For example, Azure hound can be run as a defender which will analyze that particular tenants cloud environment and then figure out the pathways that exist for that instance. So that's there is a step precursor to setting the traps which is to find the pathways and that can be done by a defender by running this uh type of open source tools. >> Come again. >> Yes. So Azure round right. So uh so Azure is effectively so the question is doesn't Azure do that is that the question

>> correct correct so the question is about Azure round will determine the different routes that that the attacker can will take yes exactly that's what Azure hound does so it shows the set to the defender of the set of possible pathways that the attacker can take the challenge for the defender is if you run Azure hound in a production environment it will show you could be a 100 pathways it could be more than 100 and you can't do much about some of those pathways some of them you can reduce because you say oh I made a mistake there was a misconfiguration so I will reduce the permissions and try to make it safer but for the remaining ones

that you cannot stop now you have a problem because attacker has an advantage and so that's where you can create traps yes That's a good question. So the question is is the agents is there a way to have agents use certificates instead of credentials? Yes, that is certainly so strengthening prevention controls to the extent possible is always a good thing. So whatever you can prevent, you should prevent. However, there are certain things that are hard to prevent. So for example, an AM role is necessary which are shortlived credentials, but those short-lived credentials also have a certain validity. And if the attacker gets access to an instance metadata of a EC2, they can query the instance

metadata service, get access to the roles shortlived tokens which you cannot protect those through uh certificates and then use that to pivot in the environment. So certain there is some amount of attack surface that can be reduced by making the initial O stronger but there has to be some detection tools also where we assume that the prevention controls can get bypassed. Any other questions? >> Is there a way to scale this out for service? >> Right. So the question is about is there a way to scale this out for hundreds of service users that might be involved in a system. Yes. So that's where ultimately one needs some form of tooling. So the tooling can be of

various types. One can actually as a defender try to take some open source componentry and then be able to build some orchestration logic to be able to create many of them and place them at various places. It's also important for that to be able to make it dynamic because attacker might come back and when they come back if the same traps are around then they will avoid them. So so having static traps are not sufficient. So there is there are options where the defender can use uh you know their own componentry and then there are commercial options uh you know which can actually provide these type of tools as well. Okay, any other questions? you

>> do you sorry >> are you >> yeah that's a good question are you able to reduce the risk by keeping the resources private uh yes keeping the resources private is a good thing because you are reducing the risk to a reasonable extent again it's uh all about reducing the risk that is you can however the problem is initial access are many different options. The S3 bucket public access is one method but the there are many other methods. For example, the attacker can do a internetf facing exploit against a DMZ environment which is exposed because it's required for the cloud workload to do it and then get initial access or they could fish admin's laptop which is a much

straightforward case. You know the the cloud administrator's laptop can get fished and then they get access to credentials to pivot. Okay, thank you. Then uh any questions?