Chapter 46 Quiz: Cloud & Container Red Teaming¶

B — Temporary IAM credentials (AccessKeyId, SecretAccessKey, SessionToken) for the instance's IAM role; IMDSv1 is vulnerable because it requires only a simple GET request with no authentication

The EC2 Instance Metadata Service (IMDS) at 169.254.169.254 provides instance metadata including IAM role credentials. IMDSv1 responds to simple HTTP GET requests without requiring authentication headers. IMDSv2 mitigates this by requiring a session token obtained via a PUT request with a TTL header, which most SSRF vulnerabilities cannot replicate due to HTTP method restrictions.

B — The --privileged flag disables almost all security isolation, giving the container full access to the host's devices; the attacker can mount the host filesystem and escape the container

Privileged containers run with all Linux capabilities, no seccomp filtering, and access to all host devices (including block devices). An attacker can mount the host's root filesystem using mount /dev/sda1 /mnt, write SSH keys or cron jobs to the host, or use nsenter to enter the host's namespaces. This is the most straightforward container escape vector and should never be used in production.

B — Use the token to query the Kubernetes API server, enumerate cluster resources, create new pods, access secrets, and potentially escalate to cluster-admin privileges

Kubernetes service account tokens authenticate pods to the API server. If the service account has broad RBAC permissions (e.g., ClusterRole bindings with wildcard verbs on all resources), an attacker can enumerate namespaces, read secrets (including other service account tokens), create privileged pods for node escape, and potentially achieve full cluster compromise. The principle of least privilege should limit each service account to only required permissions.

B — The attacker can create a Lambda function with an attached high-privilege IAM role, then invoke the function to execute actions with that role's permissions

iam:PassRole allows attaching a specified IAM role to an AWS service. Combined with lambda:CreateFunction and lambda:InvokeFunction, the attacker creates a Lambda function with a high-privilege execution role (e.g., one with AdministratorAccess), then invokes it. The Lambda function executes with the attached role's permissions, effectively escalating the attacker's privileges. This is a well-documented AWS privilege escalation path.

B — It grants the container full control over the Docker daemon on the host, enabling container escape by creating new privileged containers or accessing the host filesystem

The Docker socket provides unrestricted access to the Docker API. A container with access to this socket can create new privileged containers mounting the host filesystem, execute commands on other containers, pull and push images, and effectively gain root-level access on the host. This is equivalent to giving the container root access on the underlying host.

B — Both provide temporary credentials accessible via a metadata endpoint, but Azure uses 169.254.169.254 with a required Metadata: true header, and credentials are obtained via the Azure Instance Metadata Service (IMDS)

Azure managed identities function similarly to AWS IAM instance roles — they provide temporary credentials via the IMDS endpoint. Azure's IMDS requires a Metadata: true HTTP header, which provides partial SSRF protection (similar to IMDSv2's PUT requirement). However, if an attacker has code execution on the VM, they can add this header directly. Both systems eliminate the need for stored credentials but introduce metadata service attack surfaces.

B — hostPID gives the pod visibility into all host processes (enabling process injection), and hostNetwork places the pod on the host's network namespace (enabling network sniffing and access to localhost-bound services)

hostPID: true shares the host's process namespace, allowing the container to see and interact with all host processes — including sending signals, reading /proc entries, and performing process injection via ptrace. hostNetwork: true places the pod on the host's network stack, enabling access to localhost-bound services (including the kubelet API), network sniffing, and bypassing network policies.

B — The attacker can enumerate all object keys (filenames and paths) in the bucket, revealing internal file structures, naming conventions, and potentially sensitive filenames — even without downloading the files themselves

S3 permissions are granular — ListBucket (s3:ListBucket) and GetObject (s3:GetObject) are separate permissions. Listing reveals object keys like backups/database-2024-prod.sql.gz, configs/production.env, or reports/financial-Q4-2024.pdf. This metadata alone provides significant intelligence about the organization's data assets and can guide further attack strategies.

B — Serverless functions execute with attached IAM roles, and overly permissive roles combined with injection vulnerabilities (command injection, SSRF) allow attackers to abuse cloud API permissions that traditional applications would not have

Serverless functions inherit the permissions of their attached IAM execution role. If a Lambda function with s3:* and iam:* permissions has a command injection vulnerability, the attacker gains those cloud API permissions. Unlike traditional servers where attackers gain OS-level shell access, serverless exploitation pivots directly into cloud API abuse, potentially impacting resources across the entire cloud account.

B — Yes — other processes in the container, dependency chains, or an attacker who gains shell access can exploit the vulnerable library; defense-in-depth requires patching regardless of direct application usage

Vulnerable libraries can be exploited through indirect dependency chains, init processes, sidecar containers, or by attackers who gain initial access through other vulnerabilities and then leverage the vulnerable library for privilege escalation or further exploitation. Defense-in-depth principles and compliance frameworks require addressing known vulnerabilities regardless of perceived exploitability. Minimal base images reduce this attack surface.

B — GCP service account key files are long-lived, non-expiring credentials that work from any location and are not automatically rotated, providing persistent access until explicitly revoked

GCP service account JSON key files contain a private key that generates authentication tokens. Unlike IMDS temporary credentials that expire in hours, these key files remain valid indefinitely until the key is deleted or the service account is disabled. They work from any network location, making them high-value targets for attackers. Google recommends Workload Identity Federation instead of exported keys.

B — Every pod in that namespace automatically receives cluster-admin credentials unless explicitly configured otherwise, giving any compromised pod full control over the entire cluster

Kubernetes automatically mounts the namespace's default service account token into every pod unless automountServiceAccountToken: false is set or a different service account is specified. Granting cluster-admin to the default service account means any pod compromise in that namespace — even through a simple application vulnerability — immediately escalates to full cluster control.

B — A highly privileged emergency access account with strict monitoring and controls, designed for use when normal administrative access paths are unavailable — red teams should verify these accounts have proper safeguards

Break-glass accounts are emergency administrative accounts that bypass normal access controls (including MFA and conditional access policies). They should have very strong passwords, be monitored with immediate alerting, and be used only when IdP or MFA systems are unavailable. Red teams should verify that these accounts exist, are properly monitored, and are not being used routinely — which would indicate a security hygiene problem.

B — Mounting host filesystems, creating cgroups to escape the container namespace, and using nsenter to enter the host's namespaces — effectively full host compromise

CAP_SYS_ADMIN is one of the most powerful Linux capabilities. Inside a container, it enables mounting filesystems (including host block devices), manipulating cgroups (a known escape vector via the cgroup release_agent technique), using ptrace on host processes, and leveraging nsenter to enter host namespaces. This capability should never be granted to production containers.

B — It indicates systemic overprivileging — any compromise of a principal with these policies grants full account control, and the blast radius of any single credential compromise extends to every resource in the account

Widespread *:* policies violate the principle of least privilege and massively expand the blast radius of credential compromise. A red team operator who compromises any single user or role with such a policy gains full account control. This finding indicates a lack of IAM governance and makes privilege escalation trivial, as there is no privilege boundary to escalate past.