PenTest+ · Domain 3 of 5

PenTest+ Domain 3: Vulnerability Discovery and Analysis

Vulnerability Discovery and Analysis covers finding weaknesses and confirming they are real: choosing the right scan type, assessing fragile ICS systems carefully, validating results against false positives, selecting exploits, and the physical security tests that bypass technical controls.

Exam weight
17%
Official objectives
3
Estimated questions estimate
~15
Suggested study time estimate
20–25 hrs

About 11 min read Reviewed October 2026

Overview

Domain 3 bridges reconnaissance and attack. It starts with vulnerability discovery using various scan types: container scans including sidecar scans, application scans (DAST, IAST, SCA, SAST with infrastructure-as-code and source code analysis, mobile scans), network scans (TCP and UDP, stealth), host-based scans, authenticated versus unauthenticated scans, secrets scanning and wireless scanning, plus industrial control system (ICS) assessment through manual methods and port mirroring, using tools such as Nikto, OpenVAS, TruffleHog, BloodHound, Nessus, Trivy and Kube-hunter. It covers analyzing output from recon, scanning and enumeration: validating results against false positives and negatives, checking scan completeness, selecting public exploits, and using scripting to validate results. It finishes with physical security concepts: tailgating, site surveys, USB drops, badge cloning and lock picking.

This domain decides what is worth attacking. Its validated findings feed the prioritization and exploitation in Domain 4.

How it's tested

Questions describe a scanning situation, scan output or a physical test and ask which scan type or tool fits, whether a finding is a false positive, or which physical technique applies. Expect performance-based items that ask you to validate or interpret results.

  • Choose the scan

    A target and constraint are given, such as a container, a web app, a fragile ICS device or a need for depth, and you must pick the scan type or tool.

  • Validate the finding

    Scan output is shown, and you must decide whether it is a true or false positive and how to confirm it.

  • Physical technique

    A physical access goal is described, and you must choose tailgating, a USB drop, badge cloning or another method.

Reasoning it through

A network vulnerability scanner reports a critical flaw on a server, but the service banner shows a version that was never affected. Rushing to exploit it is tempting. But scanners produce false positives, especially against patched or backported software. The correct step is to validate, by manually checking the version, testing the specific condition, or using a targeted script, before treating the finding as real.

Objectives 3

Official objectives from the CompTIA outline, in outline order.

3.1 Given a scenario, conduct vulnerability discovery using various techniques.Scan types across containers, applications, networks, hosts, secrets and wireless, plus ICS assessment and tools.
What it means
Discovery uses many scan types: container scans including sidecar scans, application scans (DAST, IAST, SCA, SAST covering infrastructure-as-code and source code, and mobile scans), network scans (TCP and UDP, stealth), host-based scans, authenticated versus unauthenticated scans, secrets scanning, and wireless scanning (SSID, channel and signal strength). ICS assessment uses manual methods and port mirroring. Tools include Nikto, OpenVAS, TruffleHog, BloodHound, Nessus, PowerSploit, Grype, Trivy and Kube-hunter.
What to understand
Match the scan to the target. SAST reads source code, DAST tests a running application, SCA checks third-party components, and Trivy and Kube-hunter cover containers and Kubernetes. Authenticated scans find far more than unauthenticated ones. ICS and SCADA systems are fragile, so active scanning can disrupt them, and manual assessment or passive port mirroring is safer.
How it shows up
A target and requirement are given, and you must choose the scan type or tool, especially for containers, source code or fragile ICS environments.
Common confusion
Using SAST to test a running application. SAST analyzes code at rest, and DAST tests the live application.
3.2 Given a scenario, analyze output from reconnaissance, scanning, and enumeration phases.Validating results, false positives and negatives, scan completeness, exploit selection and script validation.
What it means
Analysis validates scan, recon and enumeration results, distinguishing false positives, false negatives and true positives, checking scan completeness, troubleshooting scan configurations, selecting public exploits that match the confirmed target, and using scripting to validate results.
What to understand
Validation is the heart of this objective. A finding must be confirmed before it is exploited or reported, because false positives waste effort and false negatives hide real risk. Public exploit selection must match the exact version and configuration, and exploits from untrusted sources can be malicious or destructive. Scripts can confirm a condition without a full exploit.
How it shows up
Scan output is shown and you must judge whether it is reliable, or choose how to validate it before acting.
Common confusion
Treating every scanner finding as confirmed. Validation precedes exploitation and reporting.
3.3 Explain physical security concepts.Tailgating, site surveys, USB drops, badge cloning and lock picking.
What it means
Physical security testing covers tailgating through controlled doors, conducting site surveys, dropping USB devices to tempt staff into plugging them in, cloning access badges, and picking locks.
What to understand
Physical access often defeats strong technical controls, because an attacker at a keyboard or network port bypasses perimeter defenses. These techniques must be explicitly authorized in scope, since they carry legal and safety risk. A USB drop tests whether staff follow policy on unknown devices.
How it shows up
A physical access goal is described, and you must choose the technique, or identify the control that would stop it.
Common confusion
Assuming physical tests are always in scope. They require explicit authorization because of their legal and safety implications.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • SAST vs. DAST vs. IAST vs. SCA

    SAST reads code, DAST tests a running app, IAST instruments a running app, and SCA inventories third-party components.

    Remember
    SAST needs source, DAST needs a running target.
    Tested as
    Scan type selection.
    Trap
    Running DAST before the app is deployed.

  • Authenticated vs. unauthenticated scan

    Authenticated scans log in and see internal detail; unauthenticated scans see only external surface.

    Remember
    Authenticated scans find far more and have fewer false positives.
    Tested as
    Scan design questions.
    Trap
    Relying on unauthenticated scans for depth.

  • ICS assessment caution

    Industrial control systems are fragile and prioritize availability and safety.

    Remember
    Use manual assessment and port mirroring, not aggressive scanning.
    Tested as
    ICS and OT questions.
    Trap
    Running active scans against production ICS.

  • Container and Kubernetes scanning

    Trivy, Grype and Kube-hunter assess container images and Kubernetes clusters.

    Remember
    Match the tool to the container layer.
    Tested as
    Tool selection.
    Trap
    Using a network scanner for image vulnerabilities.

  • Secrets scanning

    TruffleHog and similar tools find exposed credentials and keys in code and files.

    Remember
    Secrets in repositories are high-value findings.
    Tested as
    Discovery questions.
    Trap
    Overlooking committed secrets.

  • BloodHound

    Maps Active Directory relationships and attack paths.

    Remember
    It reveals privilege-escalation paths in AD.
    Tested as
    Discovery and path questions.
    Trap
    Treating it as a vulnerability scanner.

  • False positive vs. false negative

    A false positive reports a vulnerability that is not there; a false negative misses a real one.

    Remember
    Validate before acting, and authenticated scans reduce false negatives.
    Tested as
    Validation questions.
    Trap
    Exploiting unvalidated findings.

  • Validation before exploitation

    Confirming a finding is real before attacking or reporting it.

    Remember
    Scan results are leads, not facts.
    Tested as
    Analysis questions.
    Trap
    Launching an exploit on a scanner finding alone.

  • Public exploit selection

    Choosing an exploit that matches the confirmed version and configuration.

    Remember
    Untrusted exploits can be malicious or destructive, so review the code.
    Tested as
    Exploit preparation questions.
    Trap
    Running exploit code from an unverified source.

  • USB drop

    Leaving USB devices for staff to find and plug in.

    Remember
    It tests policy on unknown devices and needs explicit authorization.
    Tested as
    Physical security questions.
    Trap
    Assuming it is always in scope.

  • Badge cloning

    Copying an access card to enter secured areas.

    Remember
    It defeats badge-only physical controls.
    Tested as
    Physical security questions.
    Trap
    Overlooking it when assessing physical access.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

SAST vs. DAST vs. IAST vs. SCA

ConceptMeaningKey differenceCommon trap
SAST Analyzes source or compiled code without running it Needs code, finds flaws early Expecting runtime findings
DAST Tests a running application from outside Needs a running target Running it before deployment
IAST Instruments a running application during testing Combines code and runtime views Confusing it with SAST
SCA Inventories third-party and open-source components Focuses on dependencies Using it to review custom code

Authenticated vs. unauthenticated vs. stealth scans

ConceptMeaningKey differenceCommon trap
Authenticated Scanner logs in to the target Sees configuration and patches, fewer false positives Mishandling scan credentials
Unauthenticated Scanner probes without logging in Shows the external attacker view Treating it as complete
Stealth scan Scan designed to avoid detection Lower noise, may be slower or less complete Expecting full coverage from it

False positive vs. false negative vs. true positive

ConceptMeaningKey differenceCommon trap
False positive Reported vulnerability that is not real Wastes effort if acted on Exploiting without validation
False negative Real vulnerability the scan missed Hides risk Trusting an unauthenticated scan to be complete
True positive Correctly identified real vulnerability Confirmed and actionable Assuming all findings are true positives

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Exploit on sight

    What candidates pick
    Launch an exploit immediately for every critical scanner finding.
    Why it looks right
    Fast action looks productive.
    Why it's wrong
    Scanners produce false positives. The finding must be validated against the actual version and configuration first.

    Clue to watch for The banner, version or context suggests the finding may not apply.

  2. Scan the ICS hard

    What candidates pick
    Run a full active vulnerability scan against production SCADA controllers.
    Why it looks right
    Thorough scanning finds more.
    Why it's wrong
    Active scanning can crash fragile industrial devices. Manual assessment and port mirroring are the safe methods.

    Clue to watch for The environment is ICS, SCADA or OT.

  3. SAST the running app

    What candidates pick
    Use SAST to test a deployed web application for runtime flaws.
    Why it looks right
    SAST is a known application testing method.
    Why it's wrong
    SAST analyzes source code at rest. Testing the running application is DAST.

    Clue to watch for The target is a running or deployed application.

  4. Unauthenticated is enough

    What candidates pick
    Rely on an unauthenticated scan to assess internal host security.
    Why it looks right
    It needs no credentials and is less intrusive.
    Why it's wrong
    Without logging in, the scan misses configuration and patch-level issues. Authenticated scanning is needed for depth.

    Clue to watch for The goal is internal configuration or patch assessment.

  5. Trust the exploit code

    What candidates pick
    Download and run a public exploit without reviewing it.
    Why it looks right
    It promises a quick win.
    Why it's wrong
    Untrusted exploit code can be malicious, destructive or backdoored. Review it and match it to the confirmed target first.

    Clue to watch for The exploit comes from an unverified public source.

  6. Physical is always allowed

    What candidates pick
    Attempt badge cloning or lock picking because the test is comprehensive.
    Why it looks right
    Physical access would prove real risk.
    Why it's wrong
    Physical techniques carry legal and safety risk and must be explicitly authorized in scope.

    Clue to watch for The scope does not explicitly include physical testing.

Answer framework

For any Domain 3 discovery or analysis scenario, use these steps before answering.

  1. Match the scan type and tool to the target, choosing SAST or SCA for code and components, DAST for running apps, and container tools for images.
  2. Protect fragile environments, using manual assessment and port mirroring for ICS and SCADA rather than aggressive active scans.
  3. Prefer authenticated scans when depth matters, and recognize what an unauthenticated scan will miss.
  4. Validate every finding against the real version and configuration, separating true positives from false positives before exploiting or reporting.
  5. For physical tests, confirm explicit authorization in scope before attempting tailgating, USB drops, badge cloning or lock picking, and record the evidence for the report.

Practice question

A penetration tester is scoped to assess a manufacturing plant's SCADA network, which runs legacy controllers that cannot be taken offline. Which approach to vulnerability discovery is MOST appropriate?

Want more like this? The PenTest+ practice test has questions for every domain.

Checklist

0 of 12

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Start with scan types in 3.1 and build a table mapping each to its target: SAST and source analysis for code, DAST and IAST for running apps, SCA for dependencies, container tools for images, and network and host scans for infrastructure. Learn the authenticated-versus-unauthenticated difference and the special caution for ICS.

Next, focus on validation in 3.2, which is the professional heart of the domain. Practice reading scan output and deciding whether a finding is credible, and learn safe public exploit selection. This connects directly to prioritization in Domain 4.

Then study physical security in 3.3. It is short but frequently tested, and candidates underestimate it. Know each technique and the control that counters it, and remember that physical testing needs explicit authorization.

Get hands-on with at least one vulnerability scanner and one container tool so you can read their output. Afterwards, move to Domain 4, where validated findings are prioritized and exploited.

FAQ

How much of PenTest+ PT0-003 is Domain 3?

Vulnerability Discovery and Analysis is 17% of the PT0-003 exam.

What is the difference between SAST and DAST?

SAST analyzes source or compiled code without running it. DAST tests a running application from outside. SAST finds flaws earlier, and DAST finds runtime and configuration issues.

Why not just scan ICS systems normally?

Industrial control systems are fragile and prioritize availability and safety. Active scanning can crash them, so manual assessment and passive port mirroring are used instead.

Why validate scan findings?

Scanners produce false positives. Validating against the real version and configuration prevents wasted effort and avoids reporting issues that are not actually exploitable.

Is it safe to run public exploits?

Only after reviewing the code and matching it to the confirmed target. Untrusted exploit code can be malicious or destructive.

Are physical security tests always included?

No. Tailgating, USB drops, badge cloning and lock picking carry legal and safety risk and must be explicitly authorized in the scope.

How does Domain 3 connect to Domain 4?

Domain 3 confirms which vulnerabilities are real. Domain 4 prioritizes those validated findings and exploits them.

Other Cybersecurity certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 3 knowledge

You have covered scan types, ICS caution, result validation, exploit selection and physical security. Test whether you can choose the right scan and validate findings under exam conditions.

Take the PenTest+ practice test Check your PenTest+ readiness

Keep going