9.2 Validating Scan, Recon, and Enumeration Results

Objective 3.2 Given a scenario, analyze output from reconnaissance, scanning, and enumeration phases is where PT0-003 stops treating a dashboard color as a finding. The first bullet is validate scan, reconnaissance, and enumeration results. CompTIA then names the vocabulary you must use without mixing it up: false positives, false negatives, true positives, scan completeness, and troubleshooting scan configurations. A Nessus, OpenVAS, Trivy, or Kube-hunter row that says critical is a hypothesis. It is not confirmed until you reproduce it or prove it wrong.

Domain 3 is still discovery and analysis (17 percent). Analysis here means you interrogate the output, not that you immediately search Exploit-DB. Public exploit selection is the next section. If you pick an exploit from an unvalidated plugin, you can crash a host for a bug that was never there.

False positives: the scanner was wrong

A false positive (FP) is a reported vulnerability, service, or exposure that is not actually present on the target. Classic causes are a banner match that names the wrong product or version, a plugin that keys off a default page or an SMB dialect advertisement the host no longer supports, a cached DNS name pointing at a different box, and a web scanner that treats every custom 404 page as an existing path.

Worked example: Nessus SMBv1 that is not there

Nessus reports SMBv1 enabled on 10.4.12.8 and paints it critical. That plugin often fires from a banner, a dialect list the scanner misread, or a signature that does not distinguish “the stack could theoretically speak v1” from “v1 is accepted now.” Validation is not a second identical Nessus run. Use an independent check: Nmap smb-protocols (or equivalent dialect enumeration) and smbclient negotiation against that host. If the host offers only SMBv2 and SMBv3, the Nessus SMBv1 row is a false positive. You do not select an SMBv1 public exploit. You do not write “critical SMBv1” in the report. You document the plugin, the independent evidence, and the FP classification. Scanner critical ≠ confirmed.

Exam trap: calling it a false positive because you dislike the CVSS number. Severity arguments are reporting (objective 1.4). FP means the condition is absent.

False negatives: the scanner was silent and the issue is real

A false negative (FN) is a real issue that did not appear in scan, recon, or enumeration output. CompTIA-relevant causes are a missing plugin or outdated plugin family, authentication that failed so an authenticated scan silently became unauthenticated, and a filtered host that never received the probe. A credentialed scan with a locked service account will under-report local missing patches. A web scan that never logged in will miss authenticated administrative paths. A host behind a firewall that drops the scanner’s source address looks “clean” on the dashboard and wide open from the user VLAN.

Do not treat “zero criticals” as proof. Ask whether the scan was even capable of seeing the issue.

True positives: you reproduced it

A true positive (TP) is a reported issue that independent evidence confirms. Reproduction should be the smallest authorized check that proves the condition: a version handshake, a path fetch, a configuration read — not an exploit payload.

Worked example: Kube-hunter dashboard that curl confirms

Kube-hunter reports an open Kubernetes dashboard on an in-scope control-plane address. The tester sends a simple HTTP request to that dashboard path with curl and receives the dashboard HTML (or an unauthenticated API document). That is a true positive. The hunter output and the curl evidence agree. You may later choose a public exploit or a scripted follow-up, but 3.2 first wants the classification: confirmed, reproduced, in scope.

If curl returned a login form or a 403 from an internal gateway, you would not yet call it a TP for “anonymous dashboard.” You would keep investigating or reclassify.

free PenTest+ practice questionsPractice questions with detailed explanations

Scan completeness: did the pass actually cover the scope?

Scan completeness asks whether the job finished against the authorized set, not whether the findings list is long. Incomplete scans produce both empty reports and false confidence.

Watch for credential errors: wrong domain prefix, expired password, account lockout after the first mid-scan failure, missing sudo or local-admin rights so “authenticated” was a label only. Watch for excluded IPs: the SoW carved out the domain controllers or the industrial VLAN, so their absence from the report is a limitation, not a clean bill of health. Watch for rate-limiting: an IPS or cloud WAF starts dropping the scanner after a burst, so the second half of the CIDR never got SYN probes. Watch for UDP not scanned: a TCP-only pass will miss SNMP, IKE, DNS, and other UDP services that 3.1 still expects you to consider.

Write completeness into notes the same day: percent of live hosts with successful auth, UDP included or not, and which ranges were skipped. Objective 1.4 will later call that “limitations.” Objective 3.2 calls it completeness while you still have time to rerun.

Troubleshooting scan configurations

Troubleshooting scan configurations is why a complete-looking job still produced garbage. Four exam-friendly failures:

Wrong SNMP community string. The scanner used public (or last year’s string) against devices that require a different community. You get timeouts or empty management-information-base walks — a false-negative factory for network gear — not proof that SNMP is locked down.

Dead default gateway. The scanner host’s gateway is down, pointing at a decommissioned router, or has no route to the target VLAN. Hosts look down. Completeness is zero. Fix routing before you declare the subnet empty.

WAF blocking the scanner. A web application firewall fingerprints the scanner user-agent or probe pattern and returns 403 or reset for every path. Nikto or DAST then reports a hardened site. From a browser on an allow-listed address the application may still be wide open. Tune the scan (approved bypass, authenticated session, reduced rate) only if the RoE allows WAF exceptions; otherwise record the block as a limitation.

Scanner in the wrong VLAN. The laptop or scan appliance sits on guest Wi-Fi or a user segment while the targets live on a server VLAN the firewall will not route. You are not testing the in-scope path. Move the scanner to the authorized segment or use the jump host named in the RoE.

Sequence on the exam: classify the output, then decide whether to rerun, relocate, or only then consider a public exploit. Believing the critical badge is the distractor.