[HackerNotes Ep. 200] Cloud Hacking from the Data Plane, Client-Side RCE, and Identity Confusion with 7urb0

Hacker TL;DR

• Cloud research starts with architecture. Before testing endpoints, understand what the service provisions, where customer code runs, and which identities connect the data plane to the control plane.

• Client-side bugs in cloud dashboards and deployed service instances can become RCE or account takeover when the victim's browser can trigger privileged actions or reach a managed identity.

• A shell in your own data plane is not the end of the test. Inventory credentials, binaries, network access, connectors, and control-plane calls, then test whether the provider trusted a customer-controlled instance too much.

• Identity delegation is where many cloud boundaries quietly fail. A lower-privilege user who can create a job or resource under another identity may be able to turn a confused deputy into tenant compromise.

We do subs at $25, $10, and $5, premium subscribers get access to:

– Hackalongs: live bug bounty hacking on real programs, VODs available
– Live data streams, exploits, tools, scripts & un-redacted bug reports

You can also find some hacker swag here.

Need a Pentest? We just launched CTBB Pentests!

Hack full time? Check out the Full-Time Hunter’s Guild!

Start with the bug you can actually explain

A cloud service let customers deploy an instance under its own hostname. The instance exposed a shell and had a cloud identity scoped to the customer's account. Custom code added to that deployment included a GET route that placed a query parameter into a command without safe handling.

That turned a boring-looking route into command injection. The interesting escalation was client-side: if a victim could be sent to the instance under their own account, the attacker could execute code in that victim-controlled context and retrieve the identity attached to it. The method is clear: custom glue code inside a hosted service deserves the same suspicion as an application's public API.

Call the pattern "RCE-Surf": a victim navigates to something, and the resulting server-side execution happens on the other side of the browser. You do not always need a classic XSS payload. Sometimes the useful primitive is a link, a route, or a deployment feature that makes the victim's own cloud do the work.

Cloud is a threat model, not a logo

The first question is simple: what is the cloud service actually made of?

A dashboard may be only the front door. Behind it can be a control plane that provisions resources, a data plane that processes customer traffic, managed identities, sidecars, logging services, registries, storage buckets, database connectors, and internal APIs. The exact layout changes between IaaS, PaaS, SaaS, shared deployments, and dedicated instances.

That is why reading documentation and deploying your own instance matter. Ask:

1. What compute exists for my service?

2. Which parts are shared, and which are isolated?

3. What talks to the control plane?

4. Which identities are created during deployment?

5. What does the provider assume a customer cannot see or control?

The highest-value failures usually cross one of those boundaries. A customer-controlled data plane should be treated as hostile. If the control plane assumes that instance is trustworthy, a shell in the data plane may become a path to provider infrastructure or another tenant.

Work from the data plane outward

Do not start by attacking the cloud provider's public perimeter. Start by getting code execution in your own service instance, then map what that access can reach.

The first inventory is mundane but powerful: environment variables, mounted files, binaries, local services, network routes, metadata endpoints, managed identities, and code that consumes those credentials. Database connectors, scripting engines, API proxies, and configuration parsers can be rich sinks. A service that makes connections on the customer's behalf may also expose SSRF or parser bugs.

The key question is not simply "can I get a shell?" It is "what did the provider place inside the box, and what does that box believe it is allowed to do?"

A credential may be scoped correctly to one deployment, or it may list resources across a region. A binary may call a shared service with assumptions that collapse once a customer can observe or modify the data plane. A deployment-time identity may exist only briefly, but still have enough permission to matter. Safe list and read operations, plus a second test account, can tell you whether the isolation boundary holds without blindly brute-forcing provider APIs.

The goal is to invert the trust relationship: make the control plane process data or responses controlled by the customer, then see whether it trusted them too much.

Sandboxes are applications too

The same method applies to AI code sandboxes and hosted developer tools. Turning off code execution does not necessarily remove the service that can execute code. Disabling internet access may leave an internal API that can re-enable it. A sandbox may contain binaries, connectors, or helper services that are unnecessary for the advertised feature and therefore worth investigating.

A restricted agent may be unable to run code directly while another available capability can reach a local API that still exposes code execution. The important lesson is that security settings are often modeled as independent switches even when the underlying components remain connected.

When you get a shell in a sandbox, inspect the whole composition. Look for what should not be there, what can reach the network, and which trusted provider APIs accept input from the sandbox. A sandbox escape is only one path. Credential exposure, exfiltration through an allowed service, or a control-plane confused deputy can be just as interesting.

Delegation is where tenants get mixed up

One recurring cloud failure is simple: a lower-privilege user can create a job, resource, or deployment that runs under a more privileged identity.

Imagine a multi-user service where each user receives cloud credentials scoped to their own data. If user A can create a job and choose user B's execution role, the job becomes a confused deputy. Code running inside it inherits B's permissions, even though A was never supposed to control B's resources.

The practical workflow is straightforward. Read the raw identity policies. Identify which roles can be delegated or passed through. Check prefixes, resource selectors, and service-specific conditions. Then test the boundary with separate users and separate deployments. Do not assume that an identity is safe because its name sounds narrow. Read what it can actually do.

The small storage trick that changes the origin

Public object storage adds another useful test case. The exact parameter is response-content-type=text/html. It overrides the GET response header, not the stored object metadata, so the bytes stay the same while the response says Content-Type: text/html. MinIO accepts it directly. Amazon S3 supports it only on a signed GET, including a presigned URL, even for public objects. The Voorivex writeup documents the stored-XSS pattern when the object is returned under a meaningful target origin.

That is not automatically XSS. The origin decides the impact. A file served from an isolated storage hostname is very different from the same bytes returned through cdn.target.com or a target-owned upload path. The hunter's job is to test the full delivery chain, not stop after proving that storage accepts a strange header.

Better agents start with a better threat model

AI can help with cloud research, but it should not be asked to discover the entire threat model from scratch. Give it a narrowly defined goal and a rich local context: the service documentation, the deployed instance, the binaries, the identity policies, and the calls observed during normal operation.

A focused agent can review a connector, trace credential use, enumerate a sandbox, or compare deployments. A vague instruction such as "get a shell" produces noise. The human still decides which boundary matters and what impact is in scope.

Cloud hacking rewards that architectural judgment. The useful bug is often five layers below the obvious endpoint, where the provider's assumptions about isolation, delegation, or customer control stop matching reality.

Resources

• Content-Type Override to Stored XSS on Public Objects, a write-up on response-content-type overrides, signed requests, MinIO, S3, and origin impact.

• Turb0, the research site of 7urb0.

• 7urb01 on X

That's it for the week, keep hacking!