Study guide
15.2 Container Escape, Supply Chain, and Cloud Attack Tools
CompTIA PenTest+ PT0-003
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
1.1 Current PT0-003 Exam Facts 1.2 Format, PBQs, Scoring, and Retake Policy 1.3 Recertification, CEUs, and Career Fit
2 Pre-Engagement Planning
2.1 Scope, Rules of Engagement, and Agreements 2.2 Target Selection and Assessment Types 2.3 Shared Responsibility, Legal Authorization, and Ethics
3 Collaboration, Frameworks, and Threat Modeling
3.1 Collaboration, Escalation, and Stakeholder Communication 3.2 Testing Frameworks and Methodologies 3.3 Threat Modeling: STRIDE, DREAD, and OCTAVE
4 Reporting and Remediation
4.1 Penetration Test Report Components 4.2 Findings Analysis and Remediation Recommendations
5 Information Gathering
5.1 Active vs Passive Reconnaissance 5.2 OSINT Sources and Techniques 5.3 DNS, Certificate Transparency, and Search Engine Enumeration 5.4 Network Recon, Protocol Scanning, Sniffing, and Banner Grabbing
6 Enumeration Techniques
6.1 OS Fingerprinting, Service Discovery, and Host Discovery 6.2 DNS, Directory, Share, and Account Enumeration 6.3 Secrets, Permissions, and Wireless Enumeration 6.4 WAF Enumeration, Web Crawling, and Attack Path Mapping
7 Recon Scripting and Tools
7.1 Modifying Bash, Python, and PowerShell for Recon 7.2 Recon and Enumeration Tools
8 Vulnerability Scan Types
8.1 Network, Host, Authenticated, and Wireless Scans 8.2 SAST, DAST, IAST, SCA, IaC, and Mobile Scans 8.3 Container, Secrets, and ICS Vulnerability Assessment 8.4 Core Vulnerability Scanners (Nessus, OpenVAS, Nikto)
9 Scan Analysis and Physical Security
9.1 Specialized Discovery Tools 9.2 Validating Scan, Recon, and Enumeration Results 9.3 Public Exploit Selection and Scripted Validation 9.4 Physical Security Concepts for PenTests
10 Attack Prioritization and Preparation
10.1 Target Prioritization: CVSS, CVE, CWE, and EPSS 10.2 Exploit Selection, Customization, and Attack Documentation
11 Network Attacks
11.1 On-Path, VLAN Hopping, Relay, and Multihomed Hosts 11.2 Default Credentials, Misconfigured Services, Packet Crafting, and Certificate Services
12 Authentication Attacks
12.1 Pass-the-Hash, Pass-the-Ticket, Pass-the-Token, and Kerberos Attacks 12.2 Password Attacks, MFA Fatigue, LDAP Injection, OIDC, and SAML
13 Host-Based Attacks
13.1 Privilege Escalation and Credential Dumping 13.2 Process Injection, Security Bypass, and Host Attack Tools
14 Web Application Attacks
14.1 SQL, Command, XSS, and SSTI Injection 14.2 CSRF, SSRF, Deserialization, IDOR, and Directory Traversal 14.3 LFI/RFI, Web Shells, API Abuse, JWT, and Session Hijacking
15 Cloud Attacks
15.1 IAM Misconfiguration, Metadata Service, and Exposed Storage 15.2 Container Escape, Supply Chain, and Cloud Attack Tools
16 Wireless and Social Engineering
16.1 Wireless Attacks and Tools 16.2 Phishing, Spearphishing, Whaling, Vishing, and Smishing 16.3 Physical Social Engineering and SE Tools
17 Specialized Systems
17.1 Mobile Attacks and AI Prompt/Model Attacks 17.2 OT/ICS, NFC, RFID, and Bluetooth Attacks
18 Attack Scripting and BAS
18.1 PowerShell, Python, and Bash Attack Automation 18.2 Breach and Attack Simulation (Caldera, Infection Monkey, Atomic Red Team)
19 Persistence
19.1 Scheduled Tasks, Services, Accounts, and Shells 19.2 C2, Backdoors, Rootkits, and Security-Control Tampering
20 Lateral Movement
20.1 Pivoting, Relays, and Additional Credential Capture 20.2 Remote Services: SMB, RDP, WinRM, WMI, SSH, and Others 20.3 Lateral Movement Tools and LOLbins
21 Exfiltration and Cleanup
21.1 Staging and Exfiltration 21.2 Cleanup, Restoration, and Artifact Preservation
15.2 Container Escape, Supply Chain, and Cloud Attack Tools
Key Takeaways Explain This Topic AI
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.
Last updated: August 2026
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.
When you drill mixed 4.6 stems — metadata versus escape versus 'which tool audits the account' — use the free PenTest+ practice questions and match the attack type before you match the logo.
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.