What this incident brings to light is a breach path that runs entirely through valid credentials and legitimate API calls: no zero-days, no perimeter breach, just a trusted OAuth token presented to a system that had no way of knowing the human behind it had been compromised two months earlier. That path leads directly to the question that this issue examines - how attackers reach the cloud control plane not by attacking it directly, but by acquiring the secondary credentials that sit adjacent to it and carry enough access to make the distinction irrelevant.

Siri Varma Vegiraju, Tech Lead at Microsoft Azure Security, walks through exactly this architecture in today’s feature. You can also watch the full live session on Attacking the Control Plane.

THIS WEEK’S GEO-POLITICAL NARRATIVE

Operation Cloud Hopper Was Never About the Target

Between 2014 and 2018, APT10 breached managed service providers across twelve countries rather than their actual targets — because MSPs held persistent administrative access to every client environment they served. One compromise meant access to all of them, through legitimate tools that left nothing anomalous to detect. The operational logic is identical to what makes the cloud control plane the primary objective today: the highest-value target is the trusted layer that’s between the attacker and everything they want to reach.

Narrative Link : Operation Cloud Hopper Was Never About the Target — InfoSec Relations

The Insider View

Featuring Siri Varma Vegiraju, Tech Lead at Microsoft Azure Security.

Attacking the Cloud Control Plane

The control plane is not where your data lives - it is instead the layer that governs who can reach it, enforcing identity policies, managing resource provisioning, and controlling privilege boundaries across every workload running beneath it, which means that compromising it does not give an attacker access to one system but administrative authority over the entire environment, using the cloud provider’s own tooling against every resource and identity it manages simultaneously.

That is what makes it the primary objective for any serious attacker, and understanding how they actually reach it - through the credential gaps, misconfigured identities, and forgotten API surfaces that most security teams are not actively governing , would actually be the practical starting point for anyone building or securing cloud systems today.

Siri Varma Vegiraju, Tech Lead at Microsoft Azure Security, brings years of hands-on experience analyzing and securing cloud control plane environments. This conversation covers the architecture of a control plane compromise, the specific failure modes security teams miss, and why the rise of agentic AI is introducing a new category of identity risk that most cloud security models were not designed to handle.

The Control Plane Is Where Risk Concentrates

The strategic value of the control plane has grown proportionally as global workloads consolidated onto a small number of major cloud providers. When most of the world’s enterprise infrastructure runs on five or six platforms, a successful compromise on any one of them can cascade across every organization operating on that infrastructure.

Vegiraju explains that “from a cloud infrastructure standpoint, there are majorly five or six providers where most of the workloads are hosted, and that is what becomes the primary target for attackers because, if they are able to infiltrate one of them, they get huge access to all these company resources or whatever platforms are deployed on these resources”.

Vegiraju also points as to how attackers are now operationalizing the concentration risk, arguing that AI-assisted tooling has substantially lowered the cost and time required to scan a cloud environment, enumerate resources, and identify exploitable conditions. He goes on to explain that attacks have become cheaper with the rise of large language models and agentic AI, where spinning up an agent with expertise in carrying out a network or cybersecurity attack and pointing it at a set of resources to scan and enumerate is now well within the operational reach of most threat actors.

He identifies three structural shifts widening that exposure window simultaneously: identity architectures moving from flat to hierarchical as agentic systems replace individual user accounts, passwordless authentication replacing key-based systems and introducing new access control gaps in the process, and the rise of Model Context Protocol APIs enabling agents to interact with cloud resources without the operator fully understanding the underlying API surface - each of which creates entry points into the control plane that older security models were not designed to account for.

Attackers Rarely Start at the Control Plane

Most practitioners new to cloud security assume the control plane is where attackers begin, but in practice it is almost never the initial access vector - it is the objective that the entire breach path is working toward.

What attackers actually target first are secondary accounts and credentials with high privileges: developer tokens left in repositories, JWTs with long validation windows, service accounts granted broad access to solve a specific problem and never had their scope reviewed. These credentials are easier to find, easier to acquire, and sufficient to reach the control plane through a completely legitimate path.

“If you look at a typical breach path, these secondary targets are the ones that lead to the control plane,” Vegiraju explains. “You have a private or public key that is in a GitHub repo, or a JWT token with seven days of validation, or some developer accounts. These accounts have high privileges, and once you get access to them, you can query the control plane directly.”

What makes this breach path so effective is that control plane APIs are publicly available and designed to respond to valid tokens, which means an attacker with a legitimate credential does not need to break anything - they hand the token to the API and it does exactly what it was built to do, listing the resources, enumerating the infrastructure, and returning a complete map of everything that account can reach.

“Control plane APIs are publicly available,” Vegiraju notes. “You give that token to the control plane, and the control plane lists all the resources under that account. With that structure, you can do a targeted attack and reduce your targets to the specific storage buckets or resources you actually want.”

The path from a leaked developer credential to a full inventory of an organization’s cloud infrastructure is a single authenticated API call. This is the gap most organizations are not closing, because the focus stays on hardening the control plane perimeter while the actual breach path runs through credentials that predate the perimeter controls entirely.

What a Real Attack Path Looks Like

Walking through a concrete example is the clearest way to make the mechanics visible, and Vegiraju reaches back to an attack pattern from the early cloud era, around 2012 to 2013, whose underlying conditions show up in modern environments with different names but the same exploitable structure.

The attack centered on webhooks deployed on cloud instances. A webhook, for context, is a service that accepts an incoming HTTP request, performs a task, and sends a callback to a destination the caller specifies. Common in cloud architectures, and in themselves a completely normal operational tool.

The cloud instances running these webhooks had access to the Instance Identity and Metadata Service, or IDMS. This is a local endpoint available on every virtual machine in a cloud environment. Its purpose is to give services running on the VM a way to obtain authentication tokens for other cloud resources without storing credentials locally. The pattern works in a manner where a VM needs to read from a storage account, calls the IDMS endpoint, receives a token, and passes it to the storage service to authenticate without requiring to store credentials.

The IDMS endpoint was accessible via localhost with no authentication requirement, because the design assumption at the time was that anything running on the VM was already operating within a boundary that could be relied upon - which held true until an attacker found a way to make something outside that boundary call it anyway.

An attacker submitted a cURL request to the publicly exposed webhook. The webhook executed the cURL call against the local IDMS endpoint, retrieved a valid authentication token, and returned it to the attacker in the response. From there, the attacker called the storage bucket APIs with a token that carried broad access privileges, enumerated every bucket and object in scope, and exfiltrated data without triggering a single authentication failure because every action was legitimate from the API’s perspective.

“The control plane was indirectly involved, but it was not a direct attack on the control plane,” Vegiraju explains. “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.”

Three conditions made this attack possible: an unauthenticated local endpoint, an overprivileged token, and no network controls restricting what the webhook could call outbound. None of those conditions is necessarily dangerous in isolation. Together, they created a complete breach path. This compound vulnerability pattern is what practitioners need to learn to look for, because fixing one condition while leaving the others in place does not remove the risk.

Three Places Cloud Security Teams Leave the Door Open

Vegiraju has identified three recurring gaps in how security teams approach control plane defense. Each is common enough to be structural rather than incidental.

API proliferation without inventory

Control plane APIs are not just CRUD endpoints. They include administrative APIs carrying elevated privileges, often created quickly to solve an operational problem and never formally tracked afterward.

“Sometimes these APIs have admin access,” Vegiraju explains. “In order to quickly solve a problem, a team creates an admin API with administrative privileges to what the control plane can do. When they expose it through the management API layer, only the CRUD operations are exposed. But unintentionally, the admin APIs sometimes get exposed as well.”

The deeper issue is the absence of a central inventory. “You end up spinning a bunch of these APIs and forget about them because there is no central place where you know what all APIs are available. Once you forget about them, these are publicly accessible but just not documented or listed to outside users.”

An undocumented API is still a reachable API. A human attacker working manually might miss an obscure endpoint. An agent scanning the full API surface methodically will not.

Overprivileged identities

Managed identities solve the credential rotation problem automatically, which is a real improvement over static keys. But rotation frequency does not determine access scope. The scope is still set by the operator, and it is consistently set too broadly.

“The access control still lies with me,” Vegiraju notes. “Each managed identity needs as restrictive permissions as possible. Basically, least privileges.”

An identity that can delete a storage bucket when it only needs read access to a single API endpoint is an identity an attacker can turn against its own environment without needing to escalate privileges at all. The damage potential is already built into the original configuration.

Broken regional isolation

Cloud providers organize resources into regions, and security teams often treat regional boundaries as access boundaries. They are not, unless explicitly configured to be.

“One API can access data from another region,” Vegiraju explains. “Region A has its own control plane, Region B has its own control plane, but a control plane in Region A can have permissions to access Region B, breaking the isolation factor. When a compromise happens, it becomes very hard to contain the attack and stop it.”

Regional isolation is a containment mechanism before it is a compliance concern. When a credential is compromised in one region, whether the attacker can pivot to another is entirely a function of how access scope was configured. Most organizations have not explicitly designed that boundary.

Agentic AI and the New Identity Architecture

Agentic AI systems introduce a structural challenge that flat cloud identity models were not built to handle. Understanding why requires a brief look at how cloud identity architecture has historically worked and where the new model diverges from it.

Traditional cloud identity is flat: a tenant contains accounts, each account carries a permission set, and security teams govern the scope of each permission set. The model works reasonably well when the number of identities is bounded and access patterns are predictable.

Agentic systems break both of those assumptions. An orchestrator agent directing multiple sub-agents creates a hierarchy of identities, each with its own access requirements and each representing a distinct failure point. If sub-agents share the orchestrator’s identity, a compromised sub-agent carries the full scope of the orchestrator’s permissions. The blast radius of a single compromised sub-agent becomes the blast radius of the entire system.

Vegiraju frames the principle through a practical example. “Let’s say I need to order food. The orchestrator agent knows how to do it: look at the menu, select the food, do the payment. Each of those tasks has its own sub-agent. The agent viewing the menu should not have permissions for any payment-related activity.”

The solution has two components. First, sandboxing at the AI layer establishes explicit API access lists for each agent, defining what it can reach and what it cannot. Second, each sub-agent gets its own managed identity scoped to its specific task. “Each sub-agent should get its own managed identity. You are able to control what the sub-agent can do because of what the managed identity has access to.”

Model Context Protocol APIs introduce a related complication. Agents interacting with cloud resources through MCP do not need to understand the underlying API surface. The MCP layer handles the translation. But that abstraction creates a risk: if the MCP API’s access is not explicitly scoped, an agent can reach resources it was never intended to interact with, and neither the operator nor the agent necessarily knows it is happening.

“If you are not controlling the access of this MCP API, it can lead to isolation problems where your API might result in access to resources it should not have access to,” Vegiraju explains.

The convenience and the risk are the same property. MCP makes agents powerful by abstracting away complexity. That same abstraction obscures the access boundaries that security depends on.

When the Stakes Scale Up

The security principles Vegiraju describes, network isolation, least privilege, and a complete API inventory, apply regardless of what the infrastructure supports. But the consequence of getting them wrong is not uniform across all deployments.

A compromised control plane governing a restaurant ordering platform is a recoverable incident. A compromised OAuth infrastructure governing emergency dispatch, 911 services, or financial systems operating at national scale is a different category of problem entirely.

“If the core infrastructure that governs your identities across emergency services, 911 services, fire services gets compromised, that is definitely a sovereignty problem,” Vegiraju says. “Either you are operating an emergency service or operating as simple as an inventory service. In any of the cases, the three security fundamentals stay.”

The fundamentals do not change with the stakes. What changes is the cost of every gap left unaddressed. The control plane does not know what it is governing. The teams designing and securing it do, and that is where the accountability sits.

You can also watch the full live session here.

THIS WEEK’S PERSON OF INTEREST

Danny Brickman — Co-founder and CEO, Oasis Security

Danny Brickman served in the Israeli Defense Forces in cyber research and development before co-founding Oasis Security in 2022 to address a class of identity risk associated with non-human identities which the security industry had not yet treated as a primary concern. In March 2026, Oasis raised a $120 million Series B led by Craft Ventures with participation from Sequoia Capital and Accel, following five times year-over-year ARR growth with a client base drawn predominantly from the Fortune 500.

The timing reflects a structural problem that has been building across enterprise environments. According to data cited by Palo Alto Networks, machine identities now outnumber human identities at a ratio of 82 to one, and that ratio grows with every new agent deployment, while the IAM systems governing them were designed for humans who log in, hold sessions, and get reviewed quarterly rather than for agents that act autonomously and continuously at machine speed.

At RSAC 2026, Brickman argued that the security model needs to shift from role-based to intent-based access control, because a static role assigned at deployment drifts from an agent’s actual behavior the moment its task changes, and the Vercel breach — where a developer authorized a third-party OAuth application with full read access and never reviewed it again — illustrates precisely what that governance gap costs in practice. (GovInfoSecurity, March 30, 2026)

SECURITY BRIEFS

Cloud credential theft, supply chain poisoning, and identity abuse across five incidents from the past six weeks.

UNC4899 Drains Crypto Wallets via Cloud SQL Manipulation

North Korea’s UNC4899 (TraderTraitor/Slow Pisces) opened with a trojanized Python file AirDropped to a developer’s personal device, escalated through Kubernetes container escape and CI/CD token abuse to full cloud admin access, then rewrote Cloud SQL logic to reset MFA seeds and drain high-value wallets. Google GTIG documented the full kill chain in its H1 2026 Cloud Threat Horizons Report.

Source: cloud.google.com

Lumma Stealer OAuth Chain Breaches into Vercel

A Lumma Stealer breach on a Context.ai workstation exfiltrated Google Workspace OAuth tokens, which threat actors used to pivot through a Vercel enterprise account and enumerate customer project environment variables. ShinyHunters claimed the data and listed it at $2M on BreachForums; Vercel and Google Mandiant are actively investigating.

Source: vercel.com

TeamPCP Backdoors Trivy, KICS, and LiteLLM

Between March 19 and 31, 2026, TeamPCP used stolen GitHub PATs to inject credential-harvesting scripts into Aqua’s Trivy, Checkmarx KICS, LiteLLM, and the Telnyx PyPI package, siphoning AWS, GCP, and Azure keys via IMDS and environment variables from downstream consumers. Wiz caught credential reuse across Azure, GitHub, and SaaS providers; Unit 42 published the full chain on April 9.

Source: unit42.paloaltonetworks.com

UAT-10608 Hoovers 766 Hosts into NEXUS Listener

Cisco Talos caught UAT-10608 exploiting CVE-2025-55182 (React2Shell) across 766 Next.js hosts to systematically pull AWS keys, SSH private keys, Stripe tokens, GitHub credentials, and Kubernetes service account tokens into a self-built operator dashboard called NEXUS Listener. Every hit shared the same root condition- over-permissioned identities with no need-to-know boundary.

Source: hackaws.cloud

React2Shell Unpatched Frontend Cracks LexisNexis AWS

In late February 2026, FulcrumSec exploited an unpatched React frontend at LexisNexis via React2Shell to reach its AWS environment, exfiltrating and publicly leaking roughly 2GB of customer names, user IDs, business contacts, and support tickets. LexisNexis confirmed the data predates 2020 with no active PII, but the incident is a clean case study in how app-layer debt becomes cloud-layer breach.

Source: BleepingComputer

Thank you for reading the second issue of Offensive Engineering on attacking the cloud control plane with Siri Varma Vegiraju. Part 2, covering the cloud data plane, is coming shortly.

Stay Curious, Stay Secure!

S Pattnaik

Data Practitioner

Technical Contributor, Offensive Engineering — InfoSec Relations