15.2 Container Escape, Supply Chain, and Cloud Attack Tools
Key Takeaways
- Container escape is a privileged container or a docker.sock mount that breaks isolation onto the host or node — not an IAM wildcard and not a hypervisor attack.
- Image and artifact tampering is an overwritten or unsigned deployable; supply chain is a poisoned base image, a compromised registry, or a CI pipeline that ships the poison.
- Workload runtime attacks are a malicious process inside an already running container, distinct from registry tampering and from escape to the host.
- Pacu is an AWS exploitation assessment framework; Prowler and ScoutSuite run multi-check cloud audits; Docker Bench is CIS Docker; Kube-hunter hunts Kubernetes; provider scanners are cloud-native vendor tools.
- Grype, Trivy, Nessus, and BloodHound are not the 4.6 tool list; Kube-hunter was also 3.1 discovery but remains the 4.6 Kubernetes hunter.
The rest of PT0-003 4.6 is workload attacks and the named tools. CompTIA lists image and artifact tampering, supply chain attacks, workload runtime attacks, and container escape next to the identity and storage issues in the previous section. Then it names Pacu, Docker Bench, Kube-hunter, Prowler, ScoutSuite, and cloud-native vendor tools. Exam items mix a privileged container, a poisoned base image, a cryptominer in a running pod, and a screenshot of an AWS audit tool, then wait for you to grab the wrong logo. Name the attack type first. Then pick the tool family.
Container escape: privileged, docker.sock, then the host
Container escape is leaving the container's isolation and landing on the host (or on the Kubernetes node). The container runtime (Docker, containerd, CRI-O) and the Linux kernel are supposed to keep namespaces, cgroups, and capabilities from reaching the node. Escape is what happens when that isolation is misconfigured. This is conceptual identification — not an exploit recipe, and not a hypervisor breakout.
Two exam pictures:
Privileged containers. A container started with privileged-equivalent settings — full capabilities, host PID or host network, or the cloud console checkbox that means 'this pod is privileged' — can see host devices and often act as root on the node. When you pick it: the stem says the workload is privileged, has hostPID, hostNetwork, or privileged: true in Kubernetes.
docker.sock mount. The Docker daemon socket is a root-equivalent API to the host's container engine. If a container can talk to that socket, it can ask the daemon to start a new container that mounts the host filesystem — which is escape. When you pick it: the stem shows the Docker socket mounted into an app container, or a CI job that exposed the socket 'so builds can run Docker.'
What it does: you go from 'I am app in a container' to 'I am on the node,' which then becomes metadata (instance role), kubelet, or other tenants' volumes depending on RoE. Exam trap: calling every container CVE 'escape.' A package CVE inside the image that only yields code execution in the container is a workload or image finding; it is escape only if isolation actually breaks. Trap two: treating escape as IAM wildcard policies. IAM is identity in the cloud API. Escape is host isolation. Trap three: attacking the hypervisor because you escaped a container. You escaped to the guest OS / node. The provider hypervisor remains out of scope.
Stay inside RoE. Proving the socket is mounted and that the API answers is often enough evidence. Do not demonstrate by destroying the node. A sidecar container is not automatically escape either: sidecars share the pod, not the node, unless they also carry privileged or socket-mount mistakes.
Image and artifact tampering
Image and artifact tampering is modifying a container image, package, Helm chart, function zip, VM image, or build artifact after or instead of the legitimate build, so what gets deployed is not what developers signed off. Unsigned tags, a :latest that moved, a registry that allowed overlay of payments-api:1.4, or a tampered machine image are this bullet.
When you pick it: the stem shows a digest that does not match the CI output, an image that grew an unexpected layer, or an artifact repository with overwrite permissions for every developer. Controls you recognize: image signing, immutable tags, admission controllers that require signed digests. The exam wants the attack name when those controls are missing. Tampering is not 4.5 cross-site scripting just because a tag string moved.
Supply chain attacks: poisoned base, compromised registry, CI
Supply chain attacks poison something upstream of the running workload so every deploy inherits the poison. CompTIA wants you to separate this from a one-off runtime process.
Poisoned base image. The org's standard base already contains a backdoor or a credential-stealing agent. Every app that builds from that base ships the implant. Compromised registry. Attackers push to the registry the cluster actually pulls from — including a look-alike registry hostname or credentials that allowed a write to the production repository. CI pipeline. The build system is the confused deputy of software delivery: a stolen GitHub Action token, a Jenkins agent that can push a production tag, or a pipeline that injects a step. That overlaps third-party integrations (the token) and trust relationship abuse (the pipeline role) from 15.1; on this section the effect is a supply-chain compromise of what gets built.
When you pick it: the stem is about what the pipeline or registry delivered, not about a process that appeared only after a live exec into a healthy pod. Exam trap: calling language-package mirrors the only supply chain. On 4.6, container bases, registries, and CI are first-class. Trap two: using Grype or Trivy as the 4.6 attack answer. Those were 3.1 discovery image scanners. 4.6 is performing the cloud or container attack or naming the attack type; Grype is not on the 4.6 tool list.
Workload runtime attacks
Workload runtime attacks hit a container or function that is already running. A malicious process appears inside the pod: a cryptominer, a reverse shell, a tool that scrapes environment variables for cloud keys, or a sidecar the deployment spec never defined. Runtime is 'the live workload was abused,' not 'the image in the registry was swapped' (that is tampering or supply chain) and not 'the container became the host' (that is escape).
When you pick it: the stem shows unexpected processes, a new listener in the pod, or runtime security alerting on exec. When you do not: the image digest in the registry does not match — that is artifact tampering. The pod is privileged and you are on the node — that is escape. Runtime is also not metadata SSRF: stealing instance-role creds through IMDS was 15.1. A miner that then reads environment variables is still a runtime finding with a possible metadata follow-on; name runtime first if the stem is 'unexpected process in the running container.'
4.6 tool matching (hard)
CompTIA lists six tool families. Match the job, not the logo you like.
Pacu is an AWS exploitation assessment framework. It is the cloud cousin of 'use a framework to exercise AWS attack modules' — enumerating IAM, trying to assume roles, looking at metadata-adjacent paths — inside an authorized account. When you pick it: the stem is AWS attack or assessment framework, not a CIS checklist and not a Kubernetes hunter.
Prowler and ScoutSuite are multi-check cloud audits. They walk an account (AWS and, depending on the tool, other clouds) and report CIS-like misconfigurations: public buckets, old keys, open security groups, logging gaps. When you pick them: the stem wants a read-only or audit-style sweep of many controls. They are not exploit frameworks. Exam trap: answering Pacu for 'which tool audits hundreds of CIS checks' — that is Prowler or ScoutSuite. Trap two: answering Nessus. Nessus is 3.1.
Docker Bench (Docker Bench for Security) runs CIS Docker host and daemon checks: whether the Docker daemon is locked down, whether sockets are exposed, whether containers run as root. When you pick it: the stem is a CIS benchmark of a Docker host, not a Kubernetes API hunt and not AWS IAM.
Kube-hunter hunts Kubernetes attack surface: open dashboard, anonymous API, kubelet ports, etcd. Objective 3.1 already used Kube-hunter as discovery. On 4.6, it is still the named Kubernetes hunter when the cloud or container attack scenario is a live cluster. Exam trap: kube-bench (CIS Kubernetes) is not on the 4.6 list. Docker Bench is CIS Docker. Kube-hunter is the hunter. Trap two: answering Kube-hunter for Git-history secrets — that was TruffleHog on 3.1.
Cloud-native vendor tools are the provider consoles and scanners the cloud itself ships — conceptually Amazon Inspector, Microsoft Defender for Cloud (historically Security Center), Google Security Command Center, and similar. CompTIA's bullet is the category, not a brand trivia contest. When you pick it: the stem says 'the cloud provider's own security tool' or 'vendor native assessment.' Do not invent extra product names as if they were on the exam list.
| Tool | 4.6 job | Typical stem cue | Not the answer for |
|---|---|---|---|
| Pacu | AWS exploitation assessment framework | 'Which framework assesses AWS attack paths in-account?' | CIS Docker host checks |
| Prowler | Multi-check audit of cloud controls | Hundreds of CIS or account checks, public buckets, old keys | Kubernetes dashboard hunt |
| ScoutSuite | Multi-check audit across cloud APIs | Multi-service audit snapshot | Docker daemon CIS |
| Docker Bench | CIS Docker host and daemon benchmark | Docker socket, daemon config, CIS Docker | AWS IAM exploitation |
| Kube-hunter | Kubernetes attack-surface hunter | Open dashboard, anonymous API, kubelet | Git history secrets (TruffleHog, 3.1) |
| Cloud-native vendor tools | Provider's own scanner or console | Inspector, Defender for Cloud, or Security Command Center as vendor tools | Replacing Pacu on an AWS exploit-path stem |
Worked matching
The same in-scope account from 15.1 also runs Kubernetes. A payments pod is privileged and another pod mounts docker.sock — those are container escape paths to the node, not IAM wildcards. The registry allowed an overwrite of payments-api:1.4 and the org's base image was replaced last week — image and artifact tampering and supply chain. A running pod that was healthy at deploy now has an extra mining process — workload runtime. For tools: Pacu if the stem wants an AWS exploitation assessment framework; Prowler or ScoutSuite if it wants a multi-check audit of buckets, keys, and security groups; Docker Bench if the CIS target is the Docker host; Kube-hunter if the target is the live cluster; vendor tools if the screenshot is Inspector, Defender for Cloud, or Security Command Center. Grype and Trivy remain 3.1 image CVE scanners. BloodHound remains Active Directory. Hydra remains defaults.
Sequence on the exam: identity and metadata first (15.1), then workload isolation and supply chain, then the tool family. If the stem wants AWS attack modules, Pacu. If it wants a CIS-style account audit, Prowler or ScoutSuite. If it wants CIS Docker, Docker Bench. If it wants Kubernetes exposures, Kube-hunter. If it wants the provider's own console, cloud-native vendor tools.
An application container is privileged and another pod mounts the Docker daemon socket. What is the exam-correct 4.6 reading?
Which matching of the remaining 4.6 workload attacks is exam-correct?
Which 4.6 tool match is exam-correct?