9.3 Public Exploit Selection and Scripted Validation

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.

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.