Cloud, Containers & Modern Surfaces

Cloud providers secure the underlying infrastructure; customers secure configuration, identity, data classification, and most application logic. A penetration tester’s job is almost never “hack AWS/Azure/GCP the company” — it is to assess the customer’s tenant, accounts, and workloads under written authorization.

Scope language must name accounts, subscriptions, projects, regions, and organization IDs when possible. “Our cloud” is not enough. Clarify whether production is allowed, whether control-plane enumeration is permitted, and whether social engineering of cloud support is forbidden (it usually is).

Shared multi-tenant services create hard boundaries: you may test the client’s tenant, not neighboring customers, not the provider’s management plane, and not random public buckets you found on the internet unless the engagement and law clearly allow it. Discoverability is not consent.

Think in layers: organization/tenant governance, identity and access management, network and edge, data stores, compute and serverless, CI/CD and secrets, logging and detection. Most real findings cluster in identity and data exposure, not exotic zero-days.

Cloud breaches frequently start with a leaked access key, over-broad role trust, long-lived credential, or application that can assume powerful roles. Treat every secret, token, and role chain as potential privilege escalation material.

Build a mental model: principals (users, roles, service accounts), policies (what they can do), trust relationships (who can assume whom), and resource policies (what the resource allows). Cross-account roles and federated identity multiply complexity.

During authorized assessments, inventory principals with administrative or data-read capabilities, locate keys older than policy allows, and look for policies that grant * on * or overly broad service wildcards. Prefer read-only enumeration first unless the RoE permits privilege testing.

Passwords and keys in CI variables, chat logs, Terraform state, AMIs, and user-data scripts remain classic sources of initial access. Your job is to show realistic paths, not to spray every API at maximum rate.

Object storage (S3, Azure Blob, GCS) is a frequent critical surface when public ACLs, mis-set policies, or website hosting expose sensitive data. Check listing, read, and write paths carefully under authorization — unauthorized access to third-party buckets is not “research,” it is often illegal.

Distinguish public anonymous access, authenticated-but-overshared access (any principal in the org), and signed URL leakage. Impact depends on data sensitivity: customer PII, backups, source code, and infrastructure state files change severity dramatically.

Snapshots, AMIs, and unencrypted volumes with weak sharing settings can leak entire system images. Document identifiers, sample file names (not bulk exfiltration), and a clear business impact narrative.

Proportionality: prove you can read a non-sensitive marker file or metadata listing when possible; do not download entire production datasets “to make the finding look better.”

Virtual machines, managed instances, and many container environments expose instance metadata endpoints that return temporary credentials and configuration. If an application can be tricked into requesting that endpoint (SSRF, local file include patterns, proxy abuse), the impact often becomes cloud role compromise.

Know the difference between older metadata services and hardened versions that require special headers or hop limits. Defenders increasingly block IMDSv1; operators should still check what the engagement target actually runs.

Serverless and PaaS reduce traditional OS post-exploitation but concentrate risk in function roles, environment variables, event triggers, and integration permissions. Map what each function identity can reach.

From a foothold, lateral movement may be pure API calls: list buckets, assume roles, read secrets managers, modify security groups. Capture API responses as evidence with redaction of long-lived secrets in client-facing reports.

CLI tools (provider CLIs) and assessment frameworks help inventory accounts quickly. Start with whoami-style identity checks, then expand to policy simulation, public exposure scanners, and CIS-style configuration baselines.

Configuration scanners (for example CSPM-style tools) produce volume. Experts triage: prioritize identity privilege, public data, logging disabled, and internet-exposed management planes over low-signal noise.

Rate limits, API costs, and detection matter. Unbounded enumeration can look like compromise and can incur client charges. Use scoped regions, staggered queries, and agreed windows.

Every finding needs: affected principal or resource ARN/ID, permission or misconfiguration detail, proof of access path, business impact, and a remediation that maps to least privilege, encryption, logging, and network control.

“We found a public bucket” is incomplete. Say what was readable, whether listing worked, whether writes were possible, and what data class was involved — with minimal samples.

Do not equate “AdministratorAccess on a sandbox account with no data” to the same severity as the same policy on production with customer records. Context is the difference between fear and accurate risk.

If you obtain temporary credentials via metadata, document TTL, attached policies, and what those credentials could reach in a controlled check agreed with the client. Avoid creating lasting backdoors unless explicitly authorized for purple-team exercises.

Cloud findings often become multi-team tickets: IAM, platform, app owners, and compliance. Write so each audience can act without a call.

A container packages application code and dependencies with Linux isolation primitives (namespaces, cgroups, capabilities). Isolation quality depends on runtime configuration, kernel, and whether dangerous privileges were granted.

Compromise of an application inside a container is still a finding even without escape: secrets in environment variables, cloud roles via the node or service account, and network reachability to internal APIs often matter more than a flashy breakout demo.

Dangerous patterns include running as root unnecessarily, privileged containers, hostPath mounts of sensitive host paths, disabled seccomp/AppArmor/SELinux, and Docker socket mounts. Each turns a web bug into host or cluster risk.

Always separate: (1) vuln in app, (2) weak container config, (3) weak orchestrator identity, (4) weak cluster network policy. Conflating them produces confused reports.

Base images with unpatched OS packages, leaked secrets baked into layers, and untrusted registries are common. Static scanners find known CVEs and misconfigurations; they do not prove exploitability in context, but they prioritize investigation.

Check for secrets in image history, overly broad ENTRYPOINT scripts, and debug tooling left in production images. Prefer distroless or minimal images as remediation guidance.

CI systems that can push to production registries are high-value targets. Compromise of the pipeline may be more severe than compromise of a single running pod.

Document image digests, registry paths, and scanner evidence. Avoid dumping entire vulnerability databases into the executive summary — summarize critical classes and true business impact.

Kubernetes exposes an API server that is the source of truth for workloads. Anonymous or weakly authenticated API access, dashboard exposure, and overly powerful service accounts are classic findings.

RBAC binds subjects (users, groups, service accounts) to verbs on resources. Look for cluster-admin bindings, wildcards, and service accounts mounted into pods that can create privileged pods or read all secrets.

etcd, kubelet APIs, and cloud provider integrations can expand impact. Many managed K8s services change which layers you may touch — stay inside customer-authorized boundaries.

Network policies, ingress controllers, and service types (LoadBalancer/NodePort) determine how far a foothold can travel. Flat cluster networks remain common in labs and in poorly segmented production.

From a developer laptop context: kubeconfig permissions, accessible namespaces, and ability to exec into pods. From a compromised pod: service account token, reachable API, secrets, and cloud metadata from the node environment.

Safe order: identity and permission discovery, then non-destructive resource listing, then controlled proof for high-impact access (for example reading a non-sensitive config map vs dumping all secrets).

Tools that “hunt” for weak RBAC or exposed dashboards accelerate work but generate false positives. Validate every critical claim manually with kubectl or API calls in scope.

Noise and availability: aggressive scanning of the API server or kubelets can stress control planes. Use agreed rates and maintenance windows when required.

Container breakout research is advanced and kernel-version dependent. In professional tests, privilege flags and mount abuse often provide more reliable, reportable paths than obscure CVEs.

Node compromise typically yields all pods on the node, kubelet credentials material, and often cloud instance roles. That is a cluster-level event — escalate to the client immediately if unexpected in a limited web test.

Workloads with cloud IAM roles via OIDC/IRSA (or equivalents) create direct cloud privilege from pod compromise. Map the trust from service account to cloud permissions explicitly in findings.

Never install cryptominers, persistent cluster malware, or unexplained DaemonSets “to demonstrate impact” unless a red-team RoE explicitly authorizes persistence and cleanup is planned.

Good K8s findings name namespace, service account, binding, and capability. Screenshots of dashboards help executives; YAML and RBAC snippets help engineers.

Remediation themes: least-privilege RBAC, no privileged pods by policy (PSS/PSA, OPA/Gatekeeper, Kyverno), network policies, secret management (not env-in-plain), image signing/admission, and API server exposure controls.

Separate operational hygiene (old images, missing resource limits) from exploitable paths. Both can appear, but severity must reflect attacker usefulness.

Retest criteria should be clear: binding removed, pod security enforced, secret rotated, public endpoint closed.