Study guide
9.2 Validating Scan, Recon, and Enumeration Results
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.2 Validating Scan, Recon, and Enumeration Results
Key Takeaways Explain This Topic AI
PT0-003 objective 3.2 starts with validation: a scanner label of critical is not a confirmed finding until you reproduce or refute it.
A false positive is a reported issue that is not really there, such as a Nessus SMBv1 plugin when nmap and smbclient show only SMBv2.
A false negative is a real issue the scan missed because a plugin was missing, authentication failed, or the host was filtered.
A true positive is independently reproduced, such as kube-hunter reporting an open dashboard that curl fetches as HTML.
Scan completeness and troubleshooting cover credential errors, excluded IPs, rate limits, UDP never scanned, wrong SNMP community strings, a dead default gateway, a WAF blocking the scanner, and a scanner sitting on the wrong VLAN.
Last updated: August 2026
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.
When you drill false-positive versus true-positive stems, use the free PenTest+ practice questions and ask whether the evidence reproduced the issue or only repeated the scanner’s wording.
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.
- Result Meaning Worked cue
- False positive Reported, not really present Nessus SMBv1 vs nmap/smbclient showing only SMBv2
- False negative Present, not reported Locked scan account, missing plugin, filtered host
- True positive Reported and reproduced Kube-hunter open dashboard confirmed with curl
- Incomplete scan Scope not actually covered Credential errors, excluded IPs, rate-limit, UDP skipped
Bad configuration Tool could not see the target correctly Wrong community string, dead gateway, WAF block, wrong VLAN
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.