Lab 02 Vulnerability Scanning and Analysis

Mission: Your reconnaissance has identified the target’s exposed services. Your next responsibility is to determine which exposures represent genuine security weaknesses. You will perform vulnerability discovery, analyze scanner results, validate selected findings safely, prioritize vulnerabilities, and document evidence before any exploitation is attempted.

Mission Information

Item	Details
Certification	CompTIA PenTest+
Difficulty	Intermediate
Estimated Time	2–3 hours
Primary Skills	Vulnerability discovery, analysis, validation, prioritization
Attacker System	Kali Linux
Target	Metasploitable 2 or another intentionally vulnerable VM
Primary Tools	Nmap, Nmap NSE, Greenbone/OpenVAS where available, curl, searchsploit
Input	Lab 01 Attack Surface Discovery
Output	Vulnerability Assessment Report

Learning Objectives

By completing this lab, you should be able to:

• distinguish scanning from exploitation;

• configure a vulnerability scan appropriately;

• identify vulnerabilities associated with exposed services;

• understand authenticated versus unauthenticated scanning;

• interpret CVE and CVSS information;

• distinguish vulnerabilities from informational findings;

• correlate multiple sources of evidence;

• investigate false positives;

• manually validate findings without unnecessarily exploiting them;

• prioritize findings using technical and business context;

• document reproducible evidence;

• recommend remediation;

• prepare findings for a penetration-testing report.

1. Scenario

You are continuing the authorized penetration test from Lab 01 — Reconnaissance and Attack Surface Discovery.

Your reconnaissance identified several exposed network services on the target.

Example:

Target: 192.168.56.105

21/tcp    FTP
22/tcp    SSH
80/tcp    HTTP
139/tcp   NetBIOS
445/tcp   SMB
3306/tcp  MySQL

These are examples only.

Use the results from your own Lab 01 scan.

The client now authorizes vulnerability assessment against:

Authorized Target: 192.168.56.105

Permitted:
- TCP/UDP scanning
- Service enumeration
- Vulnerability scanning
- Safe vulnerability detection
- Version analysis
- Configuration analysis
- Non-destructive validation

Not Permitted:
- Denial of service
- Destructive exploitation
- Data modification
- Persistence
- Testing outside the authorized target

2. Lab Architecture

Continue using the isolated environment from Lab 01.

             PenTest+ Lab Network
              192.168.56.0/24
                      |
          +-----------+-----------+
          |                       |
          |                       |
   +-------------+         +-------------+
   | Kali Linux  |         | Vulnerable  |
   | Assessment  | ------> | Target VM   |
   +-------------+         +-------------+
   | .101        |         | .105        |
   +-------------+         +-------------+

Keep intentionally vulnerable systems on an isolated/host-only lab network.

3. Prepare Your Evidence Directory

Create a directory for this assessment:

mkdir -p ~/pentest-lab/vulnerability-assessment
cd ~/pentest-lab/vulnerability-assessment

Confirm:

pwd

Create an assessment log:

nano assessment-notes.md

Start with:

# Vulnerability Assessment Notes

## Target

IP:
Hostname:
Assessment Date:

## Scope

Authorized Target:
Authorized Services:
Restrictions:

## Reconnaissance Reference

Lab 01 Evidence:
Open Ports:
Detected Services:
Detected Versions:

## Vulnerability Findings

## Validation Notes

## False Positives

## Remediation Recommendations

4. Phase 1 — Establish the Vulnerability Baseline

Before running a vulnerability scanner, review the reconnaissance evidence from Lab 01.

Run a fresh service scan:

nmap -sV 192.168.56.105

Save it:

nmap -sV 192.168.56.105 -oA baseline-services

You should receive:

baseline-services.nmap
baseline-services.xml
baseline-services.gnmap

Your first question should be:

What exactly is exposed?

Create a table.

Port	Service	Product	Version	Assessment Required
21	FTP	Discovered product	Version	Yes
22	SSH	Discovered product	Version	Yes
80	HTTP	Web server	Version	Yes
445	SMB	SMB service	Version	Yes

Use your actual findings.

5. Vulnerability Scanning vs Exploitation

This distinction is extremely important for PenTest+.

Vulnerability scanning

Attempts to determine whether weaknesses may exist.

Examples:

Outdated software
Missing patches
Weak protocols
Unsafe configurations
Exposed services
Known CVEs
Default configurations

Validation

Attempts to determine whether a reported weakness actually applies to the target.

Exploitation

Attempts to actively leverage a vulnerability to produce an impact.

Think of the workflow as:

Discovery
    ↓
Potential Vulnerability
    ↓
Analysis
    ↓
Validation
    ↓
Confirmed Finding
    ↓
Risk Assessment
    ↓
Exploitation

Exploitation occurs only when permitted by the Rules of Engagement.

6. Phase 2 — Perform Nmap Vulnerability Discovery

Nmap’s scripting engine can assist with vulnerability discovery.

First review your discovered services:

nmap -sV 192.168.56.105

Then, against only your intentionally vulnerable lab target, run:

nmap -sV --script vuln 192.168.56.105

Save the output:

nmap -sV --script vuln 192.168.56.105 -oN nmap-vulnerability-scan.txt

Depending on the target, scripts may identify:

Known vulnerabilities
Unsafe service configurations
Weak SSL/TLS configuration
Anonymous access
Web vulnerabilities
SMB weaknesses

Do not automatically treat every result as confirmed.

7. Targeted Scanning

A professional tester should understand how to narrow testing.

Suppose your reconnaissance identified:

21/tcp
80/tcp
445/tcp

You can target only those services:

nmap -sV -p 21,80,445 192.168.56.105

Or run appropriate safe discovery scripts against a specific service rather than repeatedly scanning everything.

For example:

nmap -p 80 --script http-title,http-headers 192.168.56.105

For SMB protocol discovery:

nmap -p 445 --script smb-protocols 192.168.56.105

This illustrates an important principle:

Choose the assessment technique based on the service and objective.

8. Phase 3 — Introduce a Vulnerability Scanner

Nmap is excellent for discovery and targeted enumeration, but enterprise assessments commonly use dedicated vulnerability scanners.

Examples include:

• Greenbone/OpenVAS;

• Nessus;

• Qualys;

• Rapid7 InsightVM.

For this lab, Greenbone/OpenVAS can be used if it is available in your lab environment.

The exact setup and interface can vary by Kali/Greenbone release, so the assessment workflow matters more for PenTest+ than memorizing a particular UI.

The workflow is:

Create Target
      ↓
Define Scope
      ↓
Select Scan Configuration
      ↓
Launch Scan
      ↓
Review Findings
      ↓
Remove Noise
      ↓
Validate
      ↓
Prioritize
      ↓
Report

9. Configure the Target

In your scanner, create a target corresponding only to your authorized VM.

Example:

Name:
PenTest+ Vulnerable Server

Target:
192.168.56.105

Do not enter:

192.168.56.0/24

unless the entire subnet is explicitly authorized.

This is a subtle but important professional habit.

10. Configure the Scan

Select an appropriate vulnerability-assessment profile.

For this lab, choose a standard/full vulnerability assessment that does not intentionally perform destructive or denial-of-service testing.

Before starting, confirm:

Target correct?
Scope correct?
Scan policy correct?
Destructive checks disabled where applicable?
Lab isolated?

Then start the scan.

11. Observe Scan Behavior

While the scan runs, consider what the scanner is doing.

It may:

Discover host
       ↓
Discover ports
       ↓
Identify services
       ↓
Fingerprint versions
       ↓
Send vulnerability checks
       ↓
Compare observations with vulnerability data
       ↓
Generate findings

This explains why vulnerability scanning is more than simply searching for open ports.

12. Phase 4 — Review Scanner Findings

Once complete, examine the results.

You may encounter categories such as:

Critical
High
Medium
Low
Informational

Do not immediately focus only on Critical findings.

For every relevant finding, record:

Finding:
Affected Host:
Affected Port:
Service:
Severity:
CVSS:
CVE:
Scanner Evidence:
Potential Impact:
Confidence:

13. Understand CVE

CVE stands for:

Common Vulnerabilities and Exposures

A CVE provides a standardized identifier for a publicly known vulnerability.

Example format:

CVE-YYYY-NNNNN

A CVE identifier tells you which vulnerability is being referenced.

It does not by itself tell you the complete business risk of that vulnerability in your environment.

14. Understand CVSS

CVSS stands for:

Common Vulnerability Scoring System

It provides a standardized way to describe vulnerability severity.

Common qualitative ranges are generally interpreted as:

Score	Severity
0.0	None
0.1–3.9	Low
4.0–6.9	Medium
7.0–8.9	High
9.0–10.0	Critical

But:

CVSS ≠ Business Risk

A vulnerability with a high CVSS score may exist on an isolated development server.

Another vulnerability with a lower technical score might expose highly sensitive production information.

Professional prioritization therefore considers more than the numerical score.

15. Phase 5 — Correlate Findings

Suppose the scanner reports:

Potential vulnerable FTP service
Port: 21
Severity: High

Return to your reconnaissance evidence.

Check:

nmap -sV -p 21 192.168.56.105

Ask:

Is port 21 actually open?

Is FTP actually running?

What product was identified?

What version was identified?

Does that version match the scanner finding?

Is the vulnerable functionality enabled?

This process is correlation.

You are combining multiple evidence sources.

Nmap
   +
Scanner
   +
Manual Observation
   +
Vulnerability Intelligence
        ↓
Higher-confidence finding

16. Phase 6 — Research a Finding

For each major finding, investigate its vulnerability information.

Useful sources in a real assessment include:

Vendor security advisories
NIST NVD
CVE records
CERT advisories
Scanner references
Software release notes

Record:

CVE:
Affected Product:
Affected Versions:
Vulnerability Type:
Technical Impact:
Patch Available:
Mitigation:
References:

Do not assume a vulnerability applies simply because a version string appears similar.

17. Searchsploit for Local Research

Kali commonly includes Exploit-DB’s SearchSploit utility.

Check:

searchsploit --help

Search for the exact product/version identified in your authorized lab:

searchsploit "<product> <version>"

For example, if your scan identified an intentionally vulnerable service, search using that exact product and version.

The purpose at this stage is research, not execution.

SearchSploit results may help answer:

Is public research available?
What vulnerability class is involved?
Which versions appear affected?
Does the finding warrant deeper validation?

Do not execute exploit code simply because a search result exists.

18. Phase 7 — Manual Validation

Now select three scanner findings for non-destructive validation.

For each one, follow:

Scanner Finding
      ↓
Verify Host
      ↓
Verify Port
      ↓
Verify Service
      ↓
Verify Version
      ↓
Check Vulnerability Conditions
      ↓
Correlate References
      ↓
Confirmed / Likely / False Positive

Validation Example

Suppose a scanner reports an HTTP-related vulnerability.

Confirm the web service:

nmap -sV -p 80 192.168.56.105

Inspect headers:

curl -I http://192.168.56.105

Collect:

Server header
Application information
Response behavior
Technology indicators

Then compare this evidence with the scanner’s assumptions.

You are validating the conditions associated with the finding, not necessarily exploiting it.

19. Confidence Levels

Classify each analyzed result.

Confirmed

Strong evidence demonstrates that the vulnerable condition exists.

Likely

Evidence strongly suggests vulnerability, but full confirmation would require additional testing.

Unconfirmed

Insufficient evidence exists.

False Positive

The scanner reported a vulnerability, but manual analysis demonstrates that the reported condition does not apply.

Use a table:

Finding	Scanner	Manual Evidence	Status
Finding A	High	Version + configuration confirmed	Confirmed
Finding B	Medium	Insufficient evidence	Likely
Finding C	High	Patched/non-affected configuration	False Positive

20. What Is a False Positive?

A false positive occurs when a scanner reports a vulnerability that does not actually apply to the target.

Possible causes include:

Incorrect version fingerprinting
Backported security patches
Banner inaccuracies
Configuration differences
Scanner detection limitations
Service emulation/proxying
Incomplete information

Example:

Scanner sees old-looking version
            ↓
Assumes vulnerability
            ↓
Administrator has backported security patch
            ↓
Vulnerability condition is absent
            ↓
Potential false positive

This is why professional penetration testing requires human analysis.

21. False Negative

Also understand the opposite.

A false negative occurs when:

A vulnerability exists
        ↓
Scanner fails to identify it

Possible reasons include:

Authentication required
Custom application logic
Scanner signature missing
Network filtering
Unusual service configuration
Insufficient scanner privileges

For the exam, know:

False Positive
Scanner says vulnerability exists
but it does not.

False Negative
Scanner says nothing
but vulnerability exists.

22. Authenticated vs Unauthenticated Scanning

This is another important PenTest+ concept.

Unauthenticated scan

The scanner views the target primarily from the perspective of an external or unprivileged network observer.

It can identify:

Open ports
Exposed services
Externally observable versions
Network vulnerabilities
Some configuration weaknesses

Authenticated scan

The scanner is supplied authorized credentials.

Depending on platform and permissions, it can inspect:

Installed software
Patch status
Local configuration
Registry/settings
Packages
Security policies
Missing updates

Authenticated scanning can often provide greater visibility and reduce uncertainty.

Remember:

Unauthenticated
       ↓
External perspective

Authenticated
       ↓
Internal host visibility

Credentials must be explicitly authorized and securely handled.

23. Credentialed Scan Considerations

Before conducting authenticated scans, consider:

Credential storage
Least privilege
Credential rotation
Account lockout
Logging
Client authorization
Scanner security

Never use production credentials in a training environment.

24. Phase 8 — Analyze Vulnerability Context

For each validated finding, ask:

Exploitability

Can an attacker reach it?
Is authentication required?
Is user interaction required?
Are special conditions necessary?

Exposure

Internet-facing?
Internal?
Management network?
Restricted subnet?

Impact

Information disclosure?
Privilege escalation?
Remote code execution?
Authentication bypass?
Service compromise?

Asset importance

Development workstation?
Public web server?
Domain controller?
Database?
Critical business application?

This transforms a vulnerability list into meaningful risk information.

25. Phase 9 — Prioritize Findings

Create a prioritization matrix.

Finding	Severity	Exploitability	Exposure	Potential Impact	Priority
A	Critical	High	Network	System compromise	P1
B	High	Medium	Network	Sensitive access	P2
C	Medium	Low	Restricted	Information disclosure	P3

Do not mechanically assign priority based solely on scanner severity.

Think:

Technical Severity
       +
Exploitability
       +
Exposure
       +
Asset Criticality
       +
Business Impact
       =
Practical Priority

26. Phase 10 — Identify Vulnerability Classes

Group your findings into vulnerability classes where appropriate.

Examples:

Outdated software
Weak cryptography
Insecure protocol
Missing patch
Authentication weakness
Authorization weakness
Information disclosure
Security misconfiguration
Unnecessary service exposure
Web application weakness

This helps identify systemic security problems.

For example, ten individual outdated services may indicate a broader:

Patch Management Failure

27. Phase 11 — Develop Remediation Recommendations

A good penetration tester does not simply state:

Upgrade the server.

Provide actionable remediation.

For example:

Finding:
Legacy network protocol enabled

Recommendation:
Disable the legacy protocol where operationally possible and
require the organization's approved modern protocol version.

Additional Actions:
- Verify dependent applications
- Test configuration before production deployment
- Restrict access using network controls
- Monitor for legacy protocol usage

Recommendations should address the root security problem, not merely the scanner message.

28. Evidence Collection

For every significant finding, preserve evidence.

Example directory:

vulnerability-assessment/
│
├── baseline-services.nmap
├── baseline-services.xml
├── nmap-vulnerability-scan.txt
├── scanner-report.pdf
├── assessment-notes.md
└── findings/
    ├── finding-01.md
    ├── finding-02.md
    └── finding-03.md

Avoid collecting unnecessary sensitive data.

Evidence should be sufficient to demonstrate the finding without creating additional risk.

29. Finding Template

Create each finding using a professional structure.

# Finding 01 — [Vulnerability Name]

## Severity

Critical / High / Medium / Low / Informational

## Affected Asset

IP:
Port:
Service:

## Description

Explain the security weakness.

## Evidence

Document the evidence demonstrating the condition.

## Validation

Explain how the scanner result was manually evaluated.

## Impact

Explain what could happen if the weakness were successfully abused.

## Likelihood

Explain conditions affecting exploitation.

## CVE

CVE identifier if applicable.

## CVSS

Relevant CVSS score/vector if applicable.

## Remediation

Provide actionable remediation.

## Validation Status

Confirmed / Likely / Unconfirmed / False Positive

30. Student Challenge — Validate Three Findings

Select three findings from your scanner results.

For each:

Task 1

Verify the affected port.

Task 2

Verify the service.

Task 3

Identify the product/version where possible.

Task 4

Research the vulnerability.

Task 5

Determine the CVE if applicable.

Task 6

Review CVSS information.

Task 7

Determine whether the scanner’s assumptions match your evidence.

Task 8

Classify:

Confirmed
Likely
Unconfirmed
False Positive

Task 9

Assign remediation priority.

Task 10

Write the finding professionally.

31. Build the Vulnerability Register

Create:

# Vulnerability Register

| ID | Finding | Asset | Severity | Validation | Priority |
|---|---|---|---|---|---|
| V-01 | | | | | |
| V-02 | | | | | |
| V-03 | | | | | |

Then expand each finding in the report.

32. Required Deliverables

Submit:

01-baseline-services.txt
02-nmap-vulnerability-scan.txt
03-vulnerability-scanner-report
04-vulnerability-register.md
05-validation-notes.md
06-vulnerability-assessment-report.md

The final report should contain:

# Vulnerability Assessment Report

## 1. Executive Summary

## 2. Scope

## 3. Rules of Engagement

## 4. Methodology

## 5. Attack Surface Summary

## 6. Vulnerability Summary

## 7. Detailed Findings

## 8. Manual Validation Results

## 9. False Positives

## 10. Risk Prioritization

## 11. Remediation Recommendations

## 12. Evidence

## 13. Conclusion

33. Example Executive Summary

A good executive summary should not be a dump of scanner results.

Instead of:

The scanner discovered 34 vulnerabilities.

provide context:

The vulnerability assessment identified several security weaknesses
across the authorized target's exposed network services.

The highest-priority findings were associated with externally reachable
services where outdated or insecure configurations could increase the
likelihood of unauthorized access.

Scanner findings were correlated with service enumeration and selected
findings were manually validated before inclusion in the final results.

Remediation should prioritize confirmed high-impact vulnerabilities,
followed by reduction of unnecessary service exposure and remediation
of outdated software and insecure configurations.

34. PenTest+ Exam Checkpoints

Make sure you understand these relationships.

Discovery vs validation

Scanner identifies possibility
           ↓
Tester validates evidence
           ↓
Finding gains confidence

CVE vs CVSS

CVE
"What vulnerability is this?"

CVSS
"How severe are its technical characteristics?"

Vulnerability vs risk

Vulnerability
      ↓
Technical weakness

Risk
      ↓
Likelihood + Impact + Context

False positive

Scanner: Vulnerable
Reality: Not Vulnerable

False negative

Scanner: No Finding
Reality: Vulnerability Exists

Authenticated scanning

Credentials
    ↓
Greater internal visibility
    ↓
Potentially better configuration/patch assessment

35. Knowledge Check

Question 1

A scanner reports a critical vulnerability. Should it automatically appear as a confirmed critical finding in the penetration-test report?

Answer: No.

Analyze and validate the result, then consider technical severity, exposure, exploitability, asset importance, and business impact.

Question 2

What is the difference between CVE and CVSS?

Answer:

CVE identifies a particular publicly known vulnerability.

CVSS provides standardized metrics for describing technical vulnerability severity.

Question 3

Why might a scanner generate a false positive?

Possible reasons include:

• inaccurate fingerprinting;

• backported patches;

• unusual configurations;

• incorrect banners;

• detection limitations.

Question 4

Why are authenticated scans often more comprehensive?

Because authorized credentials can allow the scanner to inspect host-level information such as installed software, configuration, and patch status that cannot reliably be observed remotely.

Question 5

What should happen before exploitation?

Discovery
→ Analysis
→ Validation
→ Authorization Check
→ Controlled Exploitation

36. Exam-Style Scenario

You perform an assessment and receive:

Finding: Remote service vulnerability
CVSS: 9.8
Scanner Confidence: Medium
Port: 443

What should you do next?

Not:

Immediately exploit it.

Instead:

Verify service
      ↓
Identify product/version
      ↓
Review scanner evidence
      ↓
Research vulnerability
      ↓
Check prerequisites
      ↓
Safely validate
      ↓
Determine applicability

This type of decision-making is much closer to what PenTest+ expects than blindly trusting automated tools.

37. Lab Completion Checklist

• I confirmed the authorized scope.

• I reviewed Lab 01 reconnaissance evidence.

• I created a service baseline.

• I performed vulnerability discovery.

• I used a vulnerability scanner where available.

• I reviewed severity classifications.

• I understand CVE.

• I understand CVSS.

• I correlated scanner results with Nmap findings.

• I researched selected vulnerabilities.

• I manually evaluated at least three findings.

• I identified potential false positives.

• I understand false negatives.

• I understand authenticated vs unauthenticated scanning.

• I prioritized findings using context.

• I developed remediation recommendations.

• I preserved evidence.

• I produced a vulnerability register.

• I completed the assessment report.

• I did not perform unauthorized exploitation.

Key Takeaways

Automated scanners are evidence-generation tools, not substitutes for penetration testers.

A scanner may tell you:

Potential vulnerability detected.

Your responsibility is to determine:

Is the service really present?
        ↓
Is the affected version present?
        ↓
Do the vulnerability conditions apply?
        ↓
Is the result reliable?
        ↓
What is the potential impact?
        ↓
How important is the affected asset?
        ↓
How should the finding be prioritized?

The professional workflow is:

Discover → Correlate → Research → Validate → Prioritize → Remediate → Report

That distinction between scanner output and a validated security finding is one of the most important practical skills to carry into both PenTest+ and real penetration-testing work.

What’s Next?

➡️ Lab 03 — Web Application Penetration Testing

In the next lab, you will move from broad vulnerability assessment into a focused assessment of an intentionally vulnerable web application.

You will work through:

Map Application → Intercept HTTP → Enumerate → Test Inputs → Validate Weaknesses → Collect Evidence → Report

The lab will cover practical PenTest+ web-testing skills including:

• HTTP requests and responses;

• headers, cookies, sessions, and parameters;

• Burp Suite proxy configuration;

• application mapping;

• content and endpoint discovery;

• authentication and session testing;

• input-validation testing;

• SQL injection concepts and controlled validation;

• cross-site scripting;

• directory traversal concepts;

• file-related weaknesses;

• OWASP-aligned vulnerability analysis;

• evidence collection and professional web finding documentation.

The emphasis will remain on an authorized intentionally vulnerable application, giving us a practical bridge from vulnerability scanning into hands-on penetration testing.