Study guide
9.3 Public Exploit Selection and Scripted Validation
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
9.3 Public Exploit Selection and Scripted Validation
Key Takeaways Explain This Topic AI
After 3.2 validation, public exploit selection still requires the CVE, Exploit-DB entry, or Metasploit module to be inside scope.
Match the target operating system and version to the exploit’s advertised platform before you touch a module.
Check crash and denial-of-service risk against the RoE; destructive exploits are forbidden when the engagement bans them.
Scripting to validate results means repeatable checks such as curling a path, reading a status code or header, and looping across in-scope hosts.
A Metasploit auto-pwn resource script is not 3.2 scripted validation; it is unscoped exploitation.
Last updated: August 2026
Objective 3.2 does not end when you classify a true positive. CompTIA still expects public exploit selection and use scripting to validate results . Those two bullets are easy to smash together into “launch Metasploit.” The exam splits them. Selection is a decision about whether a published CVE, Exploit-DB entry, or Metasploit module is allowed and appropriate. Scripting is a repeatable check that the condition exists on this host — and the next forty hosts — without turning the check into auto-exploitation.
You already know scanner critical ≠ confirmed. This section assumes you have a true positive (or a recon/enumeration fact you independently verified). Only then do you ask whether a public exploit is the right next action.
Public exploit selection happens after validation and inside scope
Search order on the exam is: validate first , then search CVE identifiers , Exploit-DB , and Metasploit modules that claim to match the confirmed product. Do not search Exploit-DB from a false-positive SMBv1 row. Do not pull a module for a host that is out of scope even if the CVE is famous. A domain controller, a cardholder environment, or a third-party SaaS origin that appeared in a banner is not automatically fair game because a public exploit exists.
“Public” means the technique is already published — a CVE record, a vendor advisory with a proof-of-concept note, an Exploit-DB listing, a Metasploit module name. You are choosing among known items, not writing a zero-day. You still do not paste exploit payloads, shellcode, or weaponized proof-of-concept files into a study artifact or a client report. Name the CVE and the module. Describe the check you will run. Leave the payload out.
Match the target OS and version
Public exploits are picky. A Metasploit module written for a specific Windows build, a specific OpenSSH version, or a specific library in a Linux container will fail — or crash something else — if the banner was close but the build is not. Before selection, confirm:
Operating system family and build (the OS fingerprint from enumeration, plus a package or file version you actually read).
Service version, not only the default port.
Architecture and patch level when the advisory names them.
Whether a WAF, exploit-mitigation feature, or container seccomp profile sits in front of the vulnerable binary.
If Nessus said “Product 2.4.x is vulnerable” and your validation showed 2.5.1 with the vendor fix , there is no public exploit to select. If validation showed 2.4.3 matching the CVE’s affected range, the module is a candidate — still subject to crash risk and RoE.
Crash risk and rules of engagement
Many public exploits are unstable . They may restart a service, leak memory until the process dies, or take the host offline. Read the module’s reliability notes and the CVE’s impact. If the RoE forbids destructive testing , denial of service, or production crashes, you reject that module even when the version matches. After-hours is not a loophole unless the written RoE says so. “I needed a screenshot of the crash for CVSS” is not authorization.
Choose a non-destructive path when the dangerous module is banned: version check, configuration read, vendor detection script, or a safe Metasploit check routine if it does not exploit. If the only public code is a denial-of-service proof, document the true positive and stop. Impact can be described from the advisory without knocking over payroll.
Exam trap: treating Exploit-DB publication as implied scope. Publication means other people wrote about it. It does not expand the CIDR, and it does not override “no destructive exploits.”
Scripting to validate results is not auto-pwn
Use scripting to validate results means you automate the same independent check you would run once, then apply it to the rest of the in-scope set. CompTIA already tested Bash, Python, and PowerShell logic in objective 2.3. Here the point is validation at scale:
curl a path that the scanner claimed was exposed ( /dashboard/ , /admin/ , /.git/HEAD , a Kubernetes health endpoint).
Check the status code or a header (200 with dashboard HTML, Server: value, X-Kubernetes- header, missing WWW-Authenticate ).
Repeat across hosts from an allow-listed inventory file — loop, conditional, print the host that matched.
That script confirms which hosts share the true positive. It does not deliver a payload. It does not call Metasploit. It does not disable a WAF so the scanner can finish.
A Metasploit resource script that auto-exploits every address that answers is the opposite of 3.2 validation. Auto-pwn skips version matching, skips crash review, skips per-host scope, and turns a discovery analysis objective into unscoped Domain 4 attacks. If a stem offers “write a loop that exploits the first host that responds,” it is the distractor. If it offers “write a loop that curls the path and records which hosts return 200 with the dashboard title,” it is scripted validation.
Keep scripts inside the same constraints as manual tests: in-scope addresses only, rate that will not trip a ban unless the RoE allowed it, and output that you can attach as evidence. A CSV of host, URL, status, and a truncated header is a validation artifact. A shell session from an exploit module is an attack record and belongs only if exploitation was authorized after this analysis step.
- Step Question Pass Fail / stop
- Validate Is this a true positive? Independent check reproduces it FP: do not select an exploit
- Scope Is this host and action in the SoW/RoE? Named CIDR, domain, or URL Out-of-scope DC or SaaS origin
- OS and version Does the advisory match this build? Confirmed product and version Banner close, patched build
Crash / RoE Is a destructive module forbidden? Non-destructive check or allowed exploit DoS module on a no-crash engagement
Script How do I confirm the rest of the set? curl/header loop across inventory Metasploit auto-pwn resource script
Worked path: confirmed dashboard, then a careful choice
Return to the Kube-hunter true positive. Curl already fetched dashboard HTML from one control-plane address. Public exploit selection would search CVE and Exploit-DB for unauthenticated Kubernetes dashboard issues only if that cluster is in scope and the RoE allows a proof beyond the GET request. Many engagements never need a public exploit here: the curl evidence already proves exposure. If you still need to know how many nodes share the mistake, a short script curls the same path across the in-scope control-plane list and prints status codes. That is 3.2. Searching Metasploit for a cluster-takeover module before curl, or pointing that module at every RFC1918 address, is not.
The SMBv1 false positive takes the other fork. You never reach public exploit selection. There is no SMBv1 CVE to map, and a module that crashes SMBv1 stacks would be both wrong and potentially destructive.
On the exam, read the stem for when the tester searches Exploit-DB. If validation is unfinished, the answer is validate — not select. If validation is done and the RoE bans crashes, the answer is a version check or a curl loop — not the unreliable module.