How do attackers actually reach the cloud control plane, and why is it the layer that matters most to them? Siri Varma Vegiraju, a tech lead on Microsoft Azure Security, joins Offensive Engineering to walk through the real attack paths against cloud infrastructure, from stolen secondary credentials to token abuse, and to explain what defenders consistently assume they have covered when they do not.
The conversation covers the shift toward agentic AI and hierarchical identity, how managed identities are supposed to secure cloud access and where that model breaks down, the blind spots around API proliferation, and the three fundamentals Siri returns to throughout: network isolation, least privilege, and regional isolation.
Siri Varma Vegiraju is speaking independently, and the views he shares are his own.
This is the full conversation behind an issue of Offensive Engineering, the newsletter from InfoSec Relations written for engineers. Hosted by Samarpita Pattnaik, a volunteer host at InfoSec Relations. Connect with Siri Varma Vegiraju on LinkedIn.
You can read the issue, Attacking the Cloud Control Plane, drawn from this conversation.
S Pattnaik and S Eben J
The transcript below has been lightly edited for clarity.
Tell us a little about yourself and how you ended up working in cloud security.
Vegiraju: Thank you, Samarpita, for the introduction. Hello, everyone. My name is Siri Varma Vegiraju. I am currently working as a software engineer at Microsoft Cloud Security, and my experience has been on the security side of things for a while. Before Microsoft, I worked with Oracle, on their audit logging and security logging side of things. For example, let's say you end up creating a virtual machine on the cloud, so that is an audit log event. Similarly, there is network traffic that is flowing in, and we have to constantly analyze that kind of traffic to understand whatever threats are happening on the cloud network. So I was dealing with ingesting that kind of traffic and making sure it is available at a high availability rate for our security service so that they can analyze it. That is what I continue doing here at Microsoft as well, where I end up ingesting all of the network telemetry information, and I use this information to surface to the researchers where they can go and analyze it. The security space is pretty evolving right now, and I think it is a good place to be in, because with the new agentic AI, the shape of cloud security is definitely changing. So that is what has been keeping me enthusiastic about this area and its future.
Cloud services are facing a growing volume of attacks. Before we get into the control plane, set the scene. What does the current attack landscape against cloud infrastructure look like, and why is the control plane the layer that matters most to attackers?
Vegiraju: From a cloud infrastructure standpoint, there are majorly five or six providers, and most of the workloads are hosted there. That is what becomes the primary target for attackers. Because if they're able to infiltrate one of them, they get huge access to all these company resources, or whatever platforms are deployed on these resources. In the last two to three years, I believe attacks have become cheaper with the rise of large language models and agentic AI. You spin up an agent, which has expertise on how to carry out a certain kind of attack, whether a network attack or a cybersecurity attack. You spin up that agent, and you have all these resources that you are able to scan from an infrastructure standpoint, and you can tell the agent to go and, "Hey, see what all you find." So that is one major shift we are seeing. The second one is coming from an identity standpoint. Before, it was always flat. For example, there was a tenant, and the tenant had a bunch of people who had access to resources. Now, things are changing towards agents. So instead of a flat architecture, it is becoming hierarchical. That is one shift that we are seeing. And password-less identities are growing tremendously now. Three to four years ago, it was mostly private or public keys attached to an account, and that is what you would deploy for accessing any of the cloud resources. But one tricky problem with that is you have to keep rotating, otherwise once one of the keys gets compromised, your whole account gets compromised. So you have to keep rotating, which is a hassle and an operational burden. So password-less identity is also becoming very popular. And the third thing is, with the rise of model context protocols, we are just not interacting with simple APIs anymore. There are APIs that give the agents capabilities to access the cloud resources. The biggest advantage with that is now you don't have to actually understand the complete API itself. You let your agent come up with whatever parameters or whatever identity is needed, and the agent understands what needs to be done to access that particular cloud API. But the tricky part is, if you're not controlling the access of this MCP API, it can lead to isolation problems, where your API might get access to some other resources which it shouldn't have access to. So that is one more thing that needs to be kept in mind. So to summarize, password-less identities, growth of MCP APIs, and identities moving from flat to hierarchical structures. This is one thing we are actively seeing a shift towards.
When an attacker targets a cloud environment, how often is the control plane the primary objective versus a secondary target reached through lateral movement? What does that split tell us about how attackers think about cloud infrastructure?
Vegiraju: That's a very good question. So what ends up happening, if you look at a typical breach path, is that these secondary targets are the ones that lead to the control plane. What I mean by that is, for example, let's say you have a private or public key that is in a GitHub repo, or there is a JWT token that has seven days worth of validation, or some developer accounts. These accounts have high privileges, and once you are able to get access to these secondary accounts, I can go and use these accounts to actually query the control plane. For example, let's say I get access to a token for a tenant. Now, control plane APIs are publicly available. I give that token to the control plane, and the control plane lists all the resources that are under this account. For example, let's say a company called Foobar has storage accounts. Storage accounts are nothing but your S3 buckets. Now, the data is at different levels. For example, all security buckets lie under one account, and all public accounts lie under one account. With this token, I am able to identify that structure. Once I know that structure, I can do a targeted attack, and I can reduce my targets so that I do a targeted attack on these security buckets to fetch those details. So that's why what I have seen is fifty to sixty percent are on the secondary accounts, and once they get on the secondary account, that is when the rest of the targets go towards the control plane to understand where the next step needs to happen. Then from there, they move forward. That is the pattern I have seen.
Could you walk us through what a realistic control plane attack path looks like, from initial access to full environment compromise? What are the key steps, and what makes each one work?
Vegiraju: Definitely. The example I'm talking about happened in the very early stages of cloud, so maybe in 2012 or 2013. This was a very popular attack. There are something called webhooks, and what you can do with a webhook is, for example, let's say there's a service company A that is offering these webhooks. What these webhooks generally do is you can submit something to the webhook, it'll do the job for you and call your service back. That is how webhooks work. So there was once this attack where a webhook was deployed on a cloud instance, and the cloud instance has something called an identity management service. The IDMS gives back a security token. The main intention of the IDMS is that it sits on every host, and for example, let's say the VM or the service on the VM needs to talk to an S3 bucket or any cloud storage account. What the service would do is call the IDMS API, get a token, pass the token to the storage account, and the storage account would do the validation and then forward the request. What ended up happening was this IDMS, as I was saying, is on the virtual machine. You could call it with a local host endpoint, which is how it was initially, with no auth. There was no authentication to talk to that endpoint. The reason was, because of the setting of the VM inside a cloud provider platform, it was assumed to be secure. But what ended up happening was an attacker submitted a cURL call to the webhook. Now, because the webhook is running on the virtual machine, the cURL call was to the local IDMS endpoint. Whatever cURL call the webhook made, it made to the local IDMS endpoint, got the token, and sent the response back to the source, which is the attacker's place. So with this, the attacker had an identity token, a JSON web token. With that token, they called one of the storage bucket APIs to actually see what all resources are there. This is a combination of attacks, a combination of security missteps, is what I would say. One, the webhook was able to call the local host. They might have had some restriction there. Second, the access control privilege given to this token was very high. They could go and list all the buckets, list all the objects in the buckets, and list the data as well. So this is the security mistake, very broad access control. With that token, they were able to list all the data and do a data exfiltration. So in this case, the control plane was indirectly involved, but it was not a direct attack on the control plane. It was by getting the token and the combination of network security missteps plus broader access level that let the data be exfiltrated from storage buckets. This can be an example of an attack.
The management API layer is where most control plane activity happens, and also where defenders tend to have the least visibility. How do attackers abuse cloud management APIs once they have a foothold, and what does malicious API activity look like versus legitimate activity in practice?
Vegiraju: When it comes to malicious API activity, the first thing you would end up seeing is, for example, all of these management APIs. Today, cloud providers offer a lot of gateways, and gateways are where you expose your APIs through. That is where most of the controls are. For example, authentication, authorization, throttling, all of this happens at the gateway level. So in a typical attack, what ends up happening is you see a traffic spike. The reason being, a variety of attacks are being targeted at your management layer to understand what all risks are there. For example, you might be using a very old dependency in your API, which might have a particular CVE.
Managed identities, service principals, and non-human identities have become a dominant attack surface in cloud environments. How do managed identities work, how are they supposed to secure cloud access, and where does that model break down in practice?
Vegiraju: I think more cloud providers are switching towards these kinds of identities. If I have to take a step back, what are managed identities and service principals? First there were passwords, there were human accounts. Then there was a need for services to communicate with each other. That is when service principals came in. Then there came managed identities, because both the service principals and the version before that had one common problem, that is the keys. The keys need to be managed manually. For example, let's say there is a private key attached to the service principal, and that got compromised. Now, if I had to do the rotation, and I am the service provider, I might have the expertise to carry that out in a short span of time. Because once your service principal is compromised, your clock starts ticking. The reason being, the attacker now has access to these keys, and he can anytime start abusing these keys to either hack your APIs or exfiltrate data. Now, how the cloud provider solves this is using managed identities. The benefit with managed identities is all of the key management is controlled by the cloud provider itself. So they take care of rotating the keys, creating new keys, and everything. So now I, as a service operating on the cloud, don't have to worry about that. And because they are constantly rotated, my identities are pretty secure. That is the biggest advantage with managed identities. However, one problem still persists, access controls. The access control still lies with me, because I am the one telling, "Hey, for this managed identity, what all can it do? Can it delete a bucket? Can it delete a VM? Can it delete a block storage account?" These things are still controlled by me. So there is some due diligence required by the users or the service practitioners to make sure each of these managed identities has as restrictive permissions as possible. And the way to secure that would be, in most cases, your managed identities would just need read or write. For example, in the case of creating a VM or deleting a VM, it is most rare that you would carry out a destructive operation. So in most cases, it might be updating or creating some things. So that is where I would say restrict or reduce the amount of scope that your managed identity can do. And one more thing is, isolation is very important. If you have a managed identity for creating VMs, don't use that managed identity for creating storage accounts, isolate them, so that even if one gets compromised, the others are not affected. And the same thing comes to multi-region as well. Your identities should be regionally isolated, so that if one identity is exposed, only that particular region is exposed and not other regions. So to summarize, managed identities are the best practice to currently use when talking to other services. The only thing that I, as a service practitioner, need to take care of is that the scope of what the managed identity can do needs to be reduced and given as minimum as possible.
Agentic AI is changing how identities are used across cloud environments. What shifts are you seeing in how identity is managed, and what new risks does agentic AI introduce that the existing identity security model wasn't designed for?
Vegiraju: With agentic AI, what ends up happening is you have more hierarchical structures than a flat one. The meaning of that is, today there is one orchestrator agent and there are sub-agents. And the orchestrator agent is the one that tells the sub-agent what to do. For example, let's say I need to order some food. The orchestrator agent knows how to order the food. It involves looking at the menu, then selecting the food, and then doing the payment. Now what we are seeing is that each of them has their own sub-agents that are experts in doing that work. So what ends up happening is, for these agent tools, the security needs to be drilled down to that particular level. And the way to do that would be, for example, for the agent that is viewing the menu, it should not have permissions for any payment-related activity. So that is how the trickling down should happen. This is where least privilege again comes into the picture. For each of the sub-agents, they should be restricted to what they can perform. There are multiple ways to do this. One, you control at the AI layer. For example, let's say your sub-agent is the one that makes calls to either view a menu or do a payment activity. There is something called sandboxing that happens. And what that sandboxing architecture basically says is, "Hey, these are all the list of APIs that you have access to, and these are the lists that you don't have access to." That is one way to control it. And coming to an identity standpoint again, this is where each of the sub-agents should get its own managed identity. You're also able to control what the sub-agent can do because of what the managed identity has access to. So I think this is where managed identities definitely help, and basically they'll end up controlling what your agent can and cannot do.
What are the blind spots you consistently see on the defensive side when organizations assess their control plane exposure? Where do security teams tend to assume coverage that they do not actually have?
Vegiraju: One thing I've seen broadly is control plane APIs, there are a bunch of APIs like simple CRUD, create, read, update, delete. Apart from these, there are additional APIs as well. Sometimes these APIs have admin access. For example, let's say in order to quickly solve a problem, what the team has done is created an admin API which has administrative privileges over what the control plane can do. Now, when they expose it through the management API layer, only the CRUD operations are meant to be exposed. But unintentionally, or intentionally sometimes, the admin APIs also somehow get exposed. And the main problem there is something called API proliferation, where you end up spinning up a bunch of these APIs and you forget about them, because you don't have a central place where you know what all APIs are available. So that is one problem I have definitely seen. Once you forget about that, these are publicly accessible but just not documented or listed to outside users. So in the case of an agent, with the capabilities an agent has, it can quickly identify these admin capabilities and actually compromise your control plane security. So it is very important, at least now, that you document what all APIs are available, either for your control plane or data plane, and make sure they're required, and if not required, you go ahead and remove them. That is one blind spot. So to summarize, API proliferation. The other thing is, every organization should follow the least privilege or least restrictive action to their APIs. So only give access to whatever is needed, and don't provide an overprivileged account which can do anything across all your APIs. And the third thing is regional isolation is very important. What we've also seen is one API can access data from another region. For example, let's say the control plane is deployed in region one, and there are two control planes. Region A has its own control plane, region B has its own control plane. But any control plane can have permissions to access region B, so you're breaking the isolation factor. So it is very important to actually have that isolation. Otherwise, whenever there's a compromise, it becomes very hard to contain the attack and stop it.
Say a control plane access is compromised in an infrastructure that supports government services or critical national systems. How do you think about the line between a security incident there and something with much broader implications? Does that framing change how you respond?
Vegiraju: One thing I would say is it is highly dependent upon the type of system you're interacting with. For example, let's say you are using OAuth. OAuth itself is a service provider. Now, OAuth is used by multiple other services. For example, your emergency services, your nine one one services, fire services might end up using that. If the core infrastructure that governs your identities across all this gets compromised, then that is definitely a sovereignty problem. However, if a particular restaurant API or something gets compromised, then that is not. So it would highly depend upon the type of infrastructure that is getting affected. And I don't think that framing changes how you respond. Basically, whatever controls we talked about previously stay the same. Either you are operating an emergency service or you're operating something as simple as an inventory service. In any of the cases, the three security fundamentals, what I call network isolation, least privilege, and API preparation, stay. Every service provider needs to make sure these are properly covered, so that they offer the best service for their customers.
Last question. For people who are enthusiastic about building a career in cloud security today, what is the one area you would tell them to focus on that most people in the field underestimate?
Vegiraju: I would say there are two aspects to it. One, you either become a core security researcher, or you're on the engineering side of things. If you're very interested in security, in identifying vulnerabilities, pen testing, these things, this is a completely different domain. The most important thing there is you would have to stay very curious about how things are working. For example, Microsoft itself has its own security wing, and there, what they're constantly looking for is identifying vulnerabilities in their existing infrastructure. So what they end up doing is they constantly ping APIs, or they try to perform different kinds of attacks and see if they can compromise the infrastructure. That is one kind of system. The second kind of system is, in order for them to perform that, they would need some data. Now, in order to gather the data, first you have to have a source, and then you also have to collect it so that you can present it. This is the engineering aspect of it. For the engineering aspect, it would be more like a security researcher coming to you and telling you, "Hey, I need this data." And then you would go and figure out, okay, I can get this network data from a VM, and I can surface that through different data pipelines to the security researcher. So this is the engineering problem you're solving. So you really have to understand which part you like, and the only way for that would be to go ahead and try. For example, there are a bunch of vulnerabilities available outside, there's a CVE database. Pick one CVE and see if you can replicate that. Once you're able to, do it for three or four times and see if that interests you. If that is definitely something you like, then I would say start doing some open source contributions. For example, there are these bug bounty programs that Meta, Google, and all these offer, and try joining those programs and see if you can identify any vulnerabilities. Then you will know if it's something you're interested in. Otherwise, the plain software engineering path is where the engineering side of the problem comes up. And if you're already a software engineer, then you can just switch to an internal org that does security and see if that interests you. So these are the two things I would say, and the only way you would know if you would like this is to try them out.