Cloud And Hybrid Infrastructure Security practice questions

Query the local Kubernetes API server using the projected service account token mounted in the pod to extract AWS STS credentials if an IAM role is annotated.

The projected service account token authenticates to the Kubernetes API, and where an IAM role is annotated via IRSA, the pod can request AWS STS credentials through the OIDC provider. This pivots from the compromised pod into the AWS account, matching the scenario's cloud pivot requirement.

Password hashes for all synchronized accounts are stored in Microsoft Entra ID, meaning compromise of the cloud tenant could expose on-premises credentials.

PHS replicates password hashes to Microsoft Entra ID.

Insecure Direct Object Reference and unauthenticated workflow execution leading to data exfiltration.

The anonymous HTTP trigger lets any unauthenticated caller invoke the workflow, and its managed identity permissions to Blob Storage turn that into unauthorised data retrieval. This combines unauthenticated workflow execution with excessive downstream access, matching the stem's exfiltration scenario.

The attacker can leverage the service principal credentials to assign high-privilege Microsoft Entra ID roles to unauthorized user accounts.

A service principal holding PrivilegedRoleAdministrator.ReadWrite.All can authenticate to Microsoft Entra ID and call role-assignment endpoints, granting privileged directory roles to attacker-controlled accounts. This satisfies the stem's misconfiguration directly: the app role's write permission enables privilege escalation through role assignment, rather than merely reading directory data.

AWS IAM Access Analyzer and CloudTrail analysis to generate least-privilege IAM policies based on actual usage.

IAM Access Analyzer reviews CloudTrail activity to generate policies scoped to services and actions actually used, replacing the broad s3:* grant with least-privilege permissions. This directly satisfies the stem's least-privilege constraint by basing policy on observed usage rather than guesswork.

S3 Block Public Access at the AWS account level.

S3 Block Public Access at the account level applies the block at the account boundary, overriding bucket policies and ACLs that would otherwise permit public access. This satisfies the stem's requirement to prevent accidental public bucket creation across the entire AWS account, not merely within individual buckets.

Use the Docker CLI or API via the mounted socket to spin up a new container with the host root filesystem mounted at /mnt, then chroot into /mnt.

The mounted docker.sock gives the container access to the host Docker daemon API, so the tester can create a privileged container mounting the host root filesystem at /mnt, then chroot into it to gain host-level control and cluster takeover.

Exploit the command injection vulnerability to execute AWS CLI commands using the Lambda execution role, allowing privilege escalation or creation of persistent IAM backdoors.

Command injection lets the attacker run AWS CLI commands inside the Lambda runtime, which automatically assumes the execution role's temporary credentials. Because that role can update IAM policies, the attacker can attach AdministratorAccess to a controlled principal or create a backdoor access key, achieving privilege escalation and persistence without touching the host.

Configure S3 bucket default encryption with SSE-KMS on all buckets or enforce it via AWS Organizations Service Control Policies (SCPs).

Configuring S3 default encryption with SSE-KMS, combined with AWS Organizations SCPs, enforces encryption automatically across every newly created bucket without per-bucket manual effort. The SCP denies bucket creation lacking SSE-KMS, satisfying the scalability constraint for organisation-wide, customer-managed key encryption at rest.

Migrate the table encryption to use AWS Customer Managed Keys (CMKs) in AWS KMS to gain granular auditing, rotation, and access control.

AWS owned keys are shared and invisible to the account, so no key policy, audit trail, or rotation control exists. Switching to Customer Managed Keys in AWS KMS restores granular access control, CloudTrail key usage auditing, and scheduled rotation for the plaintext PII.

Mounting the host filesystem root directory via a hostPath volume (hostPath: path: /).

Mounting hostPath / exposes the node's entire filesystem inside the container, letting a process read and write host files such as /etc/shadow or kubelet credentials. That direct host access breaks the container boundary, enabling node compromise and escape.

Mounting the host's Docker daemon socket (/var/run/docker.sock) inside a container volume.

Mounting `/var/run/docker.sock` grants the container full control of the host's Docker daemon, allowing it to launch privileged containers that mount the host filesystem and escape to root on the node. This directly satisfies the stem's severe container escape criterion.

Running container processes with the root user ID (runAsUser: 0) without a security context constraints baseline.

Running as UID 0 inside a container removes the primary isolation boundary: any kernel or runtime vulnerability, mounted host path, or misconfigured capability then yields host-level root rather than an unprivileged process. Without a SecurityContextConstraints baseline enforcing non-root, nothing constrains that escalation, satisfying the stem's privilege escalation criterion.

Storing application secrets and database connection strings in plaintext within Azure App Service configuration settings.

Plaintext secrets in Azure App Service configuration settings are readable by anyone with access to the app's settings or deployment pipeline, exposing credentials that may grant access to databases, APIs or connected hybrid identity resources, directly enabling credential exposure.

An attacker compromising an on-premises account with Password Hash Sync enabled, enabling offline hash cracking of synchronized accounts if tenant is targeted.

Password Hash Sync replicates on-premises password hashes into Microsoft Entra ID, so compromising an on-premises account yields crackable NTLM hashes offline; cracking them exposes the same credentials valid in the tenant, enabling hybrid privilege escalation.

An Microsoft Entra Connect sync account possessing excessive privileges in on-premises Active Directory beyond the required MS-DS-Consistency-Guid and replication rights.

The sync account only needs MS-DS-Consistency-Guid and replication rights. Excess privileges let an attacker who compromises it modify arbitrary objects, reset passwords, or grant themselves Domain Admin, escalating from the sync service to full on-premises Active Directory control.

ec2:RunInstances combined with iam:PassRole allowing assignment of high-privilege IAM roles to newly launched instances.

RunInstances alone is harmless, but pairing it with iam:PassRole lets the attacker attach an existing high-privilege role to a new EC2 instance, then retrieve its credentials via the instance metadata service. This indirect path escalates privileges without modifying any IAM policy.

iam:CreateAccessKey combined with iam:UpdateAccessKey on an administrator user account.

Creating and updating access keys for admin users allows taking over their identity.

iam:PutUserPolicy or iam:PutRolePolicy granting administrative permissions to a user or role controlled by the attacker.

PutUserPolicy and PutRolePolicy allow inline policies to be written directly onto an identity the attacker controls, granting it administrative actions. This is direct privilege escalation because no additional role assumption or resource launch is required.

Abusing misconfigured OpenID Connect (OIDC) federation trust settings between GitHub Actions and AWS IAM roles to assume roles without proper repository conditions.

OIDC federation trust between GitHub Actions and AWS IAM roles is a genuine hybrid vector: absent repository or branch conditions in the trust policy, any workflow can assume the role, yielding cross-cloud privilege escalation without long-lived keys.

Exploiting a Server-Side Request Forgery (SSRF) vulnerability in an application to query the AWS or Azure Instance Metadata Service (IMDS) for temporary credentials.

SSRF against the Instance Metadata Service reaches the link-local endpoint unauthenticated from the instance, returning temporary IAM or managed identity credentials — a direct path from a web flaw to cloud account takeover across both providers.

Leveraging an unauthenticated API Gateway endpoint or Azure Logic App HTTP trigger to execute unauthorized backend logic or data dumping.

Unauthenticated API Gateway endpoints and Logic App HTTP triggers expose backend logic without credential checks, satisfying the stem's hybrid AWS-Azure misconfiguration vector. Both services accept anonymous invocation when authorisation is absent, letting a tester reach internal functions or dump data directly. This maps to Microsoft Entra ID-adjacent identity gaps and AWS IAM authoriser omissions in cloud assessments.

Running a container with the --privileged flag, which disables nearly all kernel namespace and capability isolation.

The --privileged flag grants all Linux capabilities and disables device cgroup restrictions, letting the container access host devices and kernel interfaces directly. That removes the isolation boundary, so a process inside can mount host filesystems or load modules to escape.

Running containers with the host PID namespace enabled (hostPID: true), allowing visibility and interaction with host processes.

Sharing the host PID namespace lets container processes see and signal host processes, and access their /proc entries. An attacker can inspect host credentials or manipulate privileged daemons, providing a direct route to host compromise without needing additional capabilities.

Having CAP_SYS_ADMIN capabilities combined with write access to the cgroup release_agent file.

CAP_SYS_ADMIN grants the privileges needed to mount cgroups and write to release_agent, a file executed by the kernel in the host namespace when a cgroup empties. Writing a payload there runs it outside the container, achieving host escape.

Exposing the Kubernetes etcd database port (2379) directly to the public internet without mutual TLS authentication.

etcd on 2379 stores all cluster state and secrets; exposing it publicly without mutual TLS lets any attacker read and write that datastore, achieving full cluster compromise. The missing mTLS removes the only authentication barrier, directly satisfying the stem's critical architecture flaw criterion.

Storing database credentials in plain Kubernetes ConfigMaps instead of encrypted Secrets or external secret stores.

ConfigMaps are stored unencrypted in etcd and readable by any principal with get permissions in the namespace, so plaintext database credentials leak through routine RBAC access or etcd compromise. Kubernetes Secrets offer base64 encoding plus optional encryption at rest, which ConfigMaps lack entirely.

Configuring admission webhook servers (ValidatingWebhookConfiguration) without validating TLS certificates or securing webhook endpoints.

Admission webhooks intercept every API request, so an unvalidated or unsecured webhook endpoint lets attackers spoof responses or inject manifests, bypassing policy enforcement cluster-wide. Skipping TLS certificate validation removes authentication between the API server and webhook, enabling man-in-the-middle manipulation of admission decisions.

The tester can exploit local file read privileges associated with Backup Operators to access the NTDS.dit file, enabling offline hash extraction and subsequent synchronization abuse.

Backup Operators grants SeBackupPrivilege, allowing files to be read regardless of ACLs. On a domain controller this permits copying NTDS.dit and the registry hives, enabling offline hash extraction. Because the account is synchronised through Microsoft Entra ID Connect, extracted credentials can then be replayed against the hybrid identity.

Public access is successfully blocked because S3 Account-level Block Public Access settings override individual bucket policies.

Account-level Block Public Access applies a restrictive guardrail that overrides permissive bucket policies, so the wildcard s3:GetObject grant cannot expose objects publicly. The bucket remains private despite the policy's lack of SourceIp or SourceArn conditions.

Create a pod specification with 'hostNetwork: true' and a 'hostPath' volume mounting '/' from the node to the container, then execute 'chroot /host' inside the new pod.

The service account token permits creating pods with cluster-admin rights, so the tester deploys a pod mounting the node's root filesystem via hostPath and enabling hostNetwork. Running chroot /host inside it breaks out to the underlying node, satisfying the escape despite privileged mode being disabled.

Use 'nsenter --target 1 --mount --uts --ipc --net --pid' to enter the host's namespaces and spawn a root shell on the host node.

CAP_SYS_ADMIN plus hostPID grants visibility of host processes and the privileges nsenter needs. Targeting PID 1 with mount, UTS, IPC, net and PID namespaces joins the host's namespaces directly, yielding a root shell outside the container boundary.