Study guide
8.3 Container, Secrets, and ICS Vulnerability Assessment
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
8.3 Container, Secrets, and ICS Vulnerability Assessment
Key Takeaways Explain This Topic AI
Container discovery on 3.1 includes image scans of registry artifacts and sidecar scans that run a companion container in the same Kubernetes pod.
Sidecar scanners share the pod so they can observe or assess the workload without rebuilding the application image.
Secrets scanning is a 3.1 scan type that hunts keys, tokens, and passwords in git history, image layers, and related artifacts — identification, not a public paste.
ICS vulnerability assessment on PT0-003 is manual assessment plus port mirroring; do not blast operational technology with default Nessus plugins.
The Purdue model still governs OT scope (levels 0–5); 3.1 adds how you observe those levels safely, without re-teaching the whole architecture chapter.
Last updated: August 2026
The rest of the 3.1 types of scans list is easy to skip in a study plan that still thinks "vulnerability scan" means Nessus versus a /24 . CompTIA also wants container scans (including sidecar ), secrets scanning , and industrial control systems (ICS) vulnerability assessment via manual assessment and port mirroring . These are discovery techniques. They are still not exploitation.
Specialized discovery tools such as BloodHound , TruffleHog , Grype , Trivy , Kube-hunter , and PowerSploit appear on the same 3.1 tool list; they are covered in the next chapter. This section is the scan type decision, not the product walkthrough.
Container scans: image versus sidecar
A container image scan inspects the image as an artifact: operating-system packages in the base layer, language runtimes, bundled libraries, and sometimes mis-set file permissions. You run it in the registry or in CI before the image is scheduled. The finding is "this tag still ships a CVE in openssl " or "this layer copies a .pem into /app ." You have not executed a container escape. You have not even needed a running pod.
A sidecar scan is a Kubernetes (and similar orchestrator) pattern. A sidecar is a companion container in the same pod as the application, sharing namespaces such as the network namespace. A sidecar scanner watches traffic, collects an inventory, or runs checks against the workload without rebuilding the application image . Exam writers use "sidecar" as a vocabulary item: if the stem says a scanner container sits beside the app in the pod, the 3.1 type is a container sidecar scan , not a CIDR SYN sweep of the worker node and not SAST of the Dockerfile alone.
Do not collapse three different objects. Scanning the Dockerfile as text is closer to SAST/IaC. Scanning the built image in the registry is an image scan. Running a sidecar next to the live workload is a runtime-adjacent container scan. Kube-hunter-style cluster tests belong with later specialized tools; the type here is still "container," with sidecar as the named subtype.
Secrets scanning as a scan type
Objective 2.2 already taught secrets enumeration during recon: you notice an AKIA key in JavaScript or a password on a guest share. Secrets scanning on 3.1 is the scanner and pipeline version of that hunt. A secrets scanner walks git history, CI logs, container layers, Helm values, and .env files looking for private keys, cloud access keys, API tokens, and passwords.
The finding is the location and type of the secret. Handling does not change from enumeration: treat it as a live credential, store it only in the agreed evidence channel, recommend rotation and a secrets manager, and do not paste it into a public chatbot or gist . Exam trap: calling a git-history AWS key "DAST" because the app is deployed, or calling it host-based OS fingerprinting. If the technique is pattern-matching credential material in repos or images, the 3.1 type is secrets scanning.
Secrets scanning overlaps container image scans when a key is baked into a layer. Report both: the image has a CVE and a copied key. Overlap does not merge the types.
ICS vulnerability assessment: observe, do not blast
ICS and operational technology (OT) are not an ordinary /24 . Programmable logic controllers (PLCs), safety instrumented systems, and engineering workstations can fault when they receive unexpected probes, long TCP connect scans, or default plugin packs written for Windows and Apache. Do not blast OT with Tenable Nessus default plugins just because the scanner can route to the address.
CompTIA lists two ICS techniques.
Manual assessment means architecture review with plant engineers, protocol allow-lists, firmware and patch inventories from the vendor or the historian — not from a reckless SYN flood — walkdowns of engineering workstations, and careful, vendor-supported checks. You are discovering weakness by understanding the system , not by treating a PLC like a misconfigured IIS box.
Port mirroring (a Switch Port Analyzer, or SPAN , session, or a network TAP) copies traffic to a sensor so you can observe ICS protocols — Modbus, DNP3, EtherNet/IP, OPC — without writing setpoints. Observation is the safety-preserving discovery method. You still need rules of engagement, a change window if anything active is later authorized, and an out-of-band way to stop if a process alarm fires.
Purdue model: cross-reference, do not retake chapter 3
The Purdue model (objective 1.3) remains the scoping map: Level 0 physical process, Level 1 basic control (PLCs), Level 2 area supervisory, Level 3 site operations, Levels 4–5 enterprise IT. Chapter 3 taught why hopping from Level 3 operations onto Level 1 logic is a safety and authorization problem. For 3.1, use that map to choose the assessment method . Enterprise IT at Level 4–5 may tolerate an authenticated Nessus pass. Level 1 controllers generally want manual review and mirrored observation, not default plugin blasts. Do not re-derive all six levels on the exam; apply them: if the stem names PLCs or a plant network, pick manual assessment and port mirroring.
Nikto against every HTTP listener in a plant is the same class of mistake. An engineering workstation might speak HTTP; a PLC that faults on a banner grab is not a web-server lab.
3.1 type Where it runs What you are trying to learn Exam trap
Container image scan Registry or CI, before schedule OS packages, bundled CVEs, copied files Calling it DAST of the cluster IP
Sidecar scan Companion container in the same pod Workload-adjacent inventory without rebuilding the app image Calling it a parking-lot SYN scan of the node
Secrets scanning Git, CI, image layers, env files Keys, tokens, passwords as a scan output Pasting the key into a public checker
ICS manual assessment Architecture, vendor data, walkdowns Weakness without unsafe probes "Just run Nessus with defaults"
ICS port mirroring SPAN/TAP copy of OT traffic Protocol and asset visibility by observation Writing a setpoint to "prove" the finding
Keep discovery inside the RoE. A sidecar you were not authorized to schedule is a change to production. A SPAN port you were not given is not a free tap. A secret you found is still a live credential. ICS observation that stays read-only is how testers leave the plant in the same state they found it — which is the point of a vulnerability assessment that is not an exploit engagement.