Cloud pentests miss the point: Kaspersky method targets trust boundaries, not bugs

By Daniel Okafor

Remote code execution inside an isolated tenant container is the beginning of a cloud penetration test, not the end. That single sentence upends how most cloud security assessments are scoped, delivered and sold. It comes from a methodology published by Kaspersky's research team, built over several years and dozens of cloud pentest projects.

The claim is blunt. Most cloud pentests to date have examined only the external layer: the management console, customer interfaces, APIs and the network perimeter. That is the surface. The real question is whether an attacker can cross trust boundaries between tenants and the provider. No single industry standard exists for this work. The outcome depends on the skill of the team performing it. That gap is the story.

What replaces the missing standard?

Kaspersky proposes a three-layer model of any cloud platform, explained through a hotel analogy:

• External: the booking website and front desk. Public APIs, the management console, IAM, SDKs.
• Overlay: the staff-only area. Service runtimes, schedulers, backup, monitoring, billing, internal APIs.
• Underlay: the utilities and physical access systems. Host operating systems, hypervisors, transport networks, storage, baseboard management controllers.

A cloud counts as well protected only if trust boundaries between these zones hold. But the authors concede the model is a simplification. Real platforms rarely fit the matrix. A hypervisor belongs to the Underlay, yet its management API may be reachable from the Overlay. The caveat matters.

What counts as a result?

The methodology is specific about what a report must answer. Five questions, in effect:

• Can an attacker read, modify or delete other tenants' data?
• Can they take over the provider's IAM service account?
• Does compromising one runtime let the attack spread to other resources, a cell, or a region?
• Can the provider's internal resources be reached from low-trust segments?
• Is a virtual environment escape possible?

A negative result is still a result, the authors argue. If a pentester cannot move from the tenant plane to the provider overlay, that shows which boundaries are enforced by controls and which rest on assumptions. The caveat follows immediately: a negative finding does not prove the boundary is impossible to cross. Other attack paths may exist.

Why clouds resist standard testing

Standards such as NIST SP 800-145 and ISO/IEC 17788 define cloud roles but prescribe no build rules. A managed database can run in an isolated virtual machine at one provider, a shared Kubernetes namespace at another, and a dedicated tenant cluster at a third. The same product name hides different internals.

Once the tenant boundary is breached, the job becomes architecture reconstruction from indirect clues: running processes, network routes, certificates, service names, agent configurations. The methodology lists fingerprinting hints. A qemu-guest-agent process signals a virtual machine. Attached Ceph/RBD volumes point to distributed block storage. Many CNI or Open vSwitch interfaces indicate a shared Kubernetes node. Every clue, the authors note, needs additional verification.

Real chains, real precedents

Four attack patterns anchor the methodology in public incidents:

• Managed database to other users' data. An isolation flaw moves SQL-level access into a shared runtime, where an unbound IAM service account token enables cross-tenant impact. The authors cite ChaosDB, where Azure Cosmos DB's Jupyter Notebook feature risked exposing other tenants' keys.
• Pod to host to cluster. A container escape plus a privileged service account compromises a multi-tenant cluster. The Azurescape chain, published by Unit 42, worked exactly this way.
• Public operation to internal compromise. A loosely validated parameter in a public API reaches an internal worker, yielding write access to image registries and future tenant workloads.
• Virtual machine escape. Guest-to-host hypervisor vectors are a real threat class, but testing them in shared infrastructure risks destructive impact and requires strict provider approval.

The ChaosDB and Azurescape cases share a lesson. What mattered was not the container escape or the feature flaw. It was obtaining a service account token valid for other tenants.

What buyers should demand

The methodology includes rules of engagement worth borrowing: permitted accounts and regions, load limits, stop conditions, handling of accidentally found credentials. Cross-tenant impact should be confirmed only against a second, controlled test tenant with synthetic data. One distinction deserves emphasis: a tenant owner testing their own resources does not automatically gain the right to probe provider infrastructure. That requires separate authorization from the platform owner.

A second article will cover the External layer and tenant-side testing of managed services. A first article that reframes the entire deliverable is a reasonable start. Whether providers adopt the five questions in their procurement remains unproven.