Lab 06 Vulnerability Assessment & Finding Validation

Mission Overview

Welcome to Lab 06 — Vulnerability Assessment & Finding Validation.

In the previous labs, you discovered hosts, identified TCP and UDP services, and enumerated how those services behave.

Now you will answer one of the most important questions in professional penetration testing:

Which observed weaknesses are actually valid security findings, and which are only scanner assumptions or incomplete indicators?

A vulnerability scanner can help you identify possible issues, but it does not replace analysis.

A professional tester must determine:

whether the affected service actually exists
whether the reported version is accurate
whether the security issue applies to that exact implementation
whether the vulnerable feature is enabled
whether a compensating control changes the exposure
whether the condition can be safely validated
what evidence supports the finding
what the real business impact is
how confident the tester should be in the conclusion

The workflow for this lab is:

Observation → Potential Vulnerability → Research → Correlate → Safely Validate → Assess Impact → Finding

Mission Goal: Analyze scanner and manual observations from authorized lab systems, distinguish potential vulnerabilities from validated findings, eliminate false positives, assess confidence and severity, and produce professional pentest findings supported by defensible evidence.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	Vulnerability Assessment
Secondary Skill	Finding Validation
Environment	GoHackersCloud Network Pentesting Lab
Input	Discovery and enumeration evidence from Labs 02–05
Primary Outcome	Validated Vulnerability Register
Safety Level	Authorized Training Systems Only

Learning Objectives

By completing this lab, you will be able to:

distinguish observations from vulnerabilities
use vulnerability scanners appropriately
interpret scanner confidence
understand CVEs and security advisories
understand CVSS at a practical level
validate software versions
assess configuration weaknesses
identify scanner false positives
recognize compensating controls
perform non-destructive manual validation
separate severity from confidence
assess environmental context
document evidence quality
classify findings consistently
write professional vulnerability findings
recommend remediation
define retest criteria

Vulnerability Assessment Methodology

Use:

Observation → Research → Correlate → Validate → Contextualize → Classify → Report

Conceptually:

Discovery / Enumeration
        │
        ▼
Potential Weakness
        │
        ▼
Scanner / Research
        │
        ▼
Affected Technology?
        │
        ▼
Affected Configuration?
        │
        ▼
Safe Validation
        │
        ├── Confirmed
        ├── Not Confirmed
        ├── False Positive
        └── Inconclusive
        │
        ▼
Business Context
        │
        ▼
Severity + Confidence
        │
        ▼
Professional Finding

The central principle is:

Scanner output is a lead. Evidence makes it a finding.

Part 1 — Revalidate Scope

Confirm your authorized targets.

Example:

192.168.56.20 — Linux Target
192.168.56.30 — Windows Target
192.168.56.40 — Optional Web Target

Confirm:

Authorized Network:

Authorized Hosts:

Vulnerability Scanning Authorized:
Yes / No

Manual Validation Authorized:
Yes / No

Exploit Execution Required:
No

Assessment Date:

Investigator:

This lab does not require destructive exploitation.

Part 2 — Create the Workspace

Create:

Network-Pentesting-Labs/
└── Lab-06/
    ├── Scope/
    ├── Notes/
    ├── Scans/
    │   ├── Vulnerability-Scanner/
    │   └── Manual-Validation/
    ├── Research/
    │   ├── CVEs/
    │   ├── Vendor-Advisories/
    │   └── Configuration/
    ├── Evidence/
    ├── Findings/
    │   ├── Validated/
    │   ├── False-Positives/
    │   └── Inconclusive/
    ├── Screenshots/
    └── Report/

Create:

Lab-06-Vulnerability-Assessment-Journal.md

Suggested journal structure:

# Lab 06 — Vulnerability Assessment & Finding Validation

## Mission Objective

## Authorization

## Target Inventory

## Service Inventory

## Scanner Configuration

## Scanner Results

## Potential Vulnerabilities

## Research

## Manual Validation

## False Positives

## Compensating Controls

## Severity Assessment

## Confidence Assessment

## Validated Findings

## Inconclusive Items

## Remediation

## Retest Criteria

## Limitations

## Conclusion

Part 3 — Import the Service Inventory

Bring forward your final Service Register from Lab 05.

Example:

Host	Port	Service	Version	Expected
Linux	22	SSH	Identified	Yes
Linux	80	HTTP	Identified	Yes
Linux	53	DNS	Identified	Yes
Windows	445	SMB	Identified	Yes
Windows	3389	RDP	Identified	Maybe

This becomes your assessment baseline.

Part 4 — Create the Vulnerability Assessment Queue

Do not scan everything without purpose.

Create:

Priority	Asset	Service	Reason
High	Windows	SMB	Network file-sharing exposure
High	Windows	RDP	Administrative access
Medium	Linux	SSH	Remote authentication
Medium	Linux	HTTP	Application exposure
Medium	Linux	DNS	Infrastructure service

Part 5 — Understand What a Vulnerability Is

A vulnerability is not simply:

Open Port

or:

Software Version

A useful model is:

Asset
 +
Weakness
 +
Reachability
 +
Relevant Configuration
 +
Security Impact

A finding becomes stronger as those elements are validated.

Part 6 — Build a Finding Classification Model

Use five categories.

Observation

A security-relevant condition was identified.

Example:

SSH is exposed from the assessed segment.

Potential Vulnerability

Evidence suggests a weakness but requires validation.

Example:

Service detection reports a version potentially associated with a known security advisory.

Validated Finding

Evidence confirms the security condition.

False Positive

The reported condition does not apply.

Inconclusive

Available evidence is insufficient for a defensible conclusion.

Part 7 — Understand Scanner Limitations

Vulnerability scanners may infer issues using:

port numbers
service banners
version fingerprints
configuration responses
protocol behavior
known signatures

Each can produce errors.

For example:

Scanner detects:
Software 1.2

Scanner concludes:
CVE-XXXX applies

But the operating system vendor may have:

Backported the security fix

without changing the upstream-looking version.

Therefore:

Version matching alone is not always enough.

Part 8 — Configure a Controlled Vulnerability Scan

Use the approved vulnerability-assessment platform available in your training environment.

The exact scanner is less important than the methodology.

Configure:

Targets:
Authorized hosts only

Ports:
Previously discovered services

Credentialed Scan:
Only if lab credentials are supplied

Unsafe / Destructive Tests:
Disabled

Denial-of-Service Checks:
Disabled

Output:
Saved

Do not enable disruptive plugins simply because the scanner supports them.

Part 9 — Record Scanner Configuration

Create:

Scanner:

Version:

Target:

Scan Profile:

Credentialed:
Yes / No

Destructive Checks:
Disabled

Ports:

Start Time:

End Time:

This is important for repeatability.

Part 10 — Run the Assessment

Perform the approved vulnerability scan against your authorized targets.

Save the results.

Do not treat the vulnerability list as your final report.

Instead, build a triage queue.

Part 11 — Create the Scanner Findings Register

Use:

Scan ID	Host	Service	Scanner Finding	Severity	Confidence
SCAN-01
SCAN-02

Add:

Scanner Evidence:

Scanner Plugin/Check:

CVE:

CVSS:

Validation Status:

Part 12 — Triage Scanner Results

Prioritize findings using:

Critical / High
       ↓
Internet/Network Reachability
       ↓
Management Services
       ↓
Authentication Weaknesses
       ↓
Known Exploitable Conditions
       ↓
Configuration Issues
       ↓
Information Disclosure

But severity alone should not determine investigation order.

Part 13 — Understand CVE

CVE stands for:

Common Vulnerabilities and Exposures

A CVE identifier may look like:

CVE-20XX-12345

A CVE identifies a publicly documented vulnerability.

It does not prove your target is affected.

Part 14 — Understand CVSS

CVSS helps estimate vulnerability severity.

Typical labels include:

Low
Medium
High
Critical

However:

CVSS describes vulnerability characteristics, not your organization’s exact business risk.

Part 15 — Separate Severity from Environmental Risk

Suppose a vulnerability has a high CVSS score.

But the service is:

Accessible only from a restricted management segment

This may reduce practical exposure.

Alternatively, a moderate vulnerability on:

an externally accessible authentication system

may be highly important.

Therefore:

Technical Severity
      +
Exposure
      +
Asset Importance
      +
Business Context
      =
Practical Risk

Part 16 — Create the Research Register

For each priority issue:

Item	Value
Asset
Service
Product
Version
CVE
Vendor Advisory
Affected Versions
Required Configuration
Fixed Version
Exploit Required	No
Applicability

Part 17 — Validate the Product

Before investigating a CVE, ask:

Do I know what software is actually running?

Correlate:

Nmap service detection
application headers
authenticated package information where supplied
operating system package records
vendor documentation

Do not rely on a single banner where better evidence exists.

Part 18 — Validate the Version

Determine:

Observed Version:

Package Version:

Vendor Package:

Patch Level:

Build:

Evidence Source:

If exact version cannot be established:

Version Confidence:
Low / Medium / High

Part 19 — Understand Backported Patches

Enterprise Linux distributions often apply security fixes without adopting the newest upstream version string.

Therefore:

Old-looking version
      ≠
Definitely vulnerable

You may need vendor package/advisory information to establish applicability.

Part 20 — Validate the Required Configuration

Many vulnerabilities only apply when a feature is enabled.

Ask:

Does the affected module exist?

Is the feature enabled?

Is the vulnerable endpoint reachable?

Is authentication required?

Does the affected protocol version apply?

Is the relevant configuration actually present?

A vulnerability that requires a disabled feature is not applicable.

Part 21 — Build the Applicability Matrix

Create:

Requirement	Present	Evidence
Affected software	Yes/No
Affected version	Yes/No/Unknown
Vulnerable feature enabled
Network reachable
Required authentication state
Compensating control

Only after completing this matrix should you classify the finding.

Part 22 — Validate Reachability

A CVE may affect a service but the relevant interface may not be remotely exposed.

Correlate with Labs 03–05.

Example:

Software:
Potentially affected

Relevant service:
Listening only on localhost

Remote network exposure may therefore not be present.

Part 23 — Assess Compensating Controls

Examples include:

firewall restrictions
reverse proxy
network segmentation
authentication
access-control lists
feature disabled
application-layer filtering
patched vendor package

Build:

Control	Present	Effect
Host firewall	Yes	Limits reachability
MFA	No	N/A
Network ACL	Yes	Management subnet only

A compensating control may reduce practical risk without eliminating the underlying weakness.

Part 24 — Perform Safe Manual Validation

Manual validation should answer a narrow question.

For example:

Is the affected protocol configuration actually enabled?

or:

Is the service reachable from this network?

or:

Does the server return the insecure configuration behavior reported by the scanner?

Avoid destructive payloads.

Part 25 — Build a Validation Plan

Before validation:

Finding ID:

Question:

Validation Method:

Expected Safe Response:

Potential Risk:

Destructive:
No

Credentials Required:
Yes / No

Evidence to Capture:

Stop Condition:

This is a professional habit.

Part 26 — Use Non-Destructive Validation First

Prefer techniques such as:

protocol negotiation
security-header review
certificate inspection
configuration checks
authentication-control review
read-only scanner plugins
service responses
supplied credential access
patch/package verification

before considering more intrusive tests.

Part 27 — Example — SSH Configuration Finding

Suppose the scanner reports:

SSH permits a deprecated cryptographic option.

Your validation should determine:

Is SSH exposed?

Is the option actually offered?

Is the result reproducible?

Does the policy require stronger algorithms?

If all are confirmed, you have a defensible configuration finding.

Part 28 — Example — Web Security Header

Suppose the scanner reports:

Missing security header.

Manually retrieve response headers.

If the header is absent consistently:

Scanner Finding:
Corroborated

Then assess whether the header is applicable and what actual risk it mitigates.

Part 29 — Example — SMB Configuration

Suppose your enumeration identified SMB.

The scanner may report security concerns relating to:

protocol version
signing
guest access
authentication
exposed shares

Do not jump from:

445/tcp open

to:

Critical SMB vulnerability

Validate the exact condition.

Part 30 — Example — TLS Finding

A scanner might report:

Weak TLS protocol enabled

Validation should determine whether the server actually negotiates the deprecated protocol.

The finding is:

Deprecated TLS protocol support was confirmed.

Not:

Encryption is completely broken.

Part 31 — Example — Anonymous Access

If a supplied training service allows anonymous access:

Validate only the designated training resource.

Record:

Unauthenticated Connection:
Successful

Resource Enumeration:
Authorized Training Share Only

Write Access:
Yes / No

Sensitive Data:
Not Accessed

Assess the actual permission level.

Part 32 — Avoid Proof by Exploitation

You do not need to compromise a host to prove every vulnerability.

For many findings:

Configuration
    +
Protocol Response
    +
Version / Advisory
    +
Reachability

is sufficient.

Professional testing seeks:

Enough evidence to validate the security condition with minimum unnecessary impact.

Part 33 — Identify False Positives

Examples:

Patched Package

Scanner flags an older-looking version, but vendor package evidence confirms the security fix.

Disabled Feature

Software is affected, but the vulnerable component is disabled.

Wrong Service

Scanner misidentifies the application.

Network Control

The vulnerable endpoint is not exposed from the assessed path.

Context Mismatch

The vulnerability applies to a different operating system/build/configuration.

Part 34 — Create the False Positive Register

Use:

ID	Scanner Finding	Reason Rejected	Evidence
FP-01		Patched package
FP-02		Feature disabled

Do not simply delete false positives.

Document why they were excluded.

Part 35 — Understand Why False Positive Documentation Matters

A professional report should demonstrate:

The tester evaluated the scanner output rather than copying it blindly.

This improves trust in the remaining findings.

Part 36 — Identify Inconclusive Results

Sometimes you cannot establish applicability.

Example:

Exact patch level unavailable

Credentialed verification unavailable

Scanner fingerprint uncertain

Classify:

Inconclusive — additional verification required.

Do not convert uncertainty into certainty.

Part 37 — Create the Inconclusive Register

ID	Potential Issue	Missing Evidence	Recommended Follow-Up
INC-01

Part 38 — Assess Evidence Quality

Use:

High Confidence

Multiple independent evidence sources confirm the condition.

Medium Confidence

Strong evidence exists but one important element is inferred.

Low Confidence

Finding depends heavily on scanner or banner assumptions.

Part 39 — Build the Confidence Register

Finding	Scanner	Manual Validation	Config Evidence	Confidence
F-01	Yes	Yes	Yes	High
F-02	Yes	No	Partial	Medium

Part 40 — Separate Confidence from Severity

A finding can be:

Low Severity
+
High Confidence

Example:

Server version disclosure.

Or:

Critical Scanner Severity
+
Low Confidence

if applicability has not been validated.

Do not mix these concepts.

Part 41 — Build the Severity Model

For each validated finding, consider:

Exploitability

Required Access

Network Reachability

Authentication Required

Potential Confidentiality Impact

Potential Integrity Impact

Potential Availability Impact

Affected Asset Importance

Then assign:

Critical

High

Medium

Low

Informational

according to your course/reporting methodology.

Part 42 — Add Environmental Context

Ask:

Is the server production-like?

Is the service administrative?

Is the host a critical business system?

Is the vulnerable path exposed to all users?

Does segmentation limit access?

Does the finding expose sensitive data?

This turns technical weakness into risk analysis.

Part 43 — Create the Risk Assessment Matrix

Finding	Technical Severity	Exposure	Asset Importance	Final Priority
F-01	High	Restricted	High	High
F-02	Medium	Broad	Medium	Medium

Part 44 — Validate Scanner Severity Independently

Do not assume:

Scanner says Critical
      =
Report says Critical

The scanner does not fully understand your environment.

Review severity yourself.

Part 45 — Build the Validated Vulnerability Register

Use:

ID	Asset	Finding	Validation	Severity	Confidence
F-01			Confirmed	High	High
F-02			Confirmed	Medium	High

Part 46 — Create a Finding Evidence Chain

A strong finding should look like:

Open Service
     ↓
Service Identified
     ↓
Relevant Configuration
     ↓
Security Advisory / Policy
     ↓
Manual Validation
     ↓
Impact
     ↓
Finding

Not:

Scanner Alert
     ↓
Finding

Part 47 — Write the Finding Title

Good titles describe the condition.

Examples:

Deprecated TLS Protocol Supported

Unauthenticated Access to Network Share

Remote Administration Service Exposed to User Segment

SMB Signing Not Required

Unnecessary Information Disclosure Through Service Banner

Avoid:

Bad Security

Critical Vulnerability Found

Hacker Can Attack Server

Part 48 — Write the Finding Description

A strong description explains:

What the issue is

Where it exists

How it was validated

Why it matters

Example:

The assessed web service accepts connections using a deprecated
TLS protocol.

The condition was initially reported by the vulnerability scanner
and subsequently confirmed through protocol negotiation from the
authorized assessment workstation.

Part 49 — Document Evidence

Evidence should include:

target
timestamp
relevant response
configuration observation
screenshot/log reference
advisory reference where appropriate

Avoid unnecessary sensitive information.

Part 50 — Document Impact

Impact should answer:

What could this weakness allow or increase the likelihood of?

Avoid sensational language.

Example:

Support for deprecated cryptographic protocols may permit clients
to establish connections using weaker security properties than
required by current organizational standards.

Part 51 — Write Remediation

Recommendations should be specific.

Weak:

Update security.

Better:

Disable deprecated protocol versions and configure the service to permit only organization-approved TLS versions and cipher suites.

Part 52 — Add Retest Guidance

Every meaningful finding should explain how to verify remediation.

Example:

Retest:

Repeat protocol-negotiation testing after configuration changes.

The deprecated protocol should no longer be accepted while approved
protocol versions remain functional.

Part 53 — Example Validated Finding — Management Exposure

Finding ID:
F-01

Title:
Remote Administrative Service Accessible from User Network

Asset:
192.168.56.30

Service:
RDP

Severity:
Medium

Confidence:
High

Description:
The RDP service is remotely reachable from the user assessment
segment.

The environment design indicates that administrative services
should be restricted to the management network.

Evidence:
TCP connectivity and service identification consistently confirm
RDP exposure from the assessed source network.

Impact:
A compromised system on the user network could directly reach an
administrative authentication surface, increasing opportunities
for credential attacks or unauthorized remote-access attempts.

Recommendation:
Restrict RDP reachability to approved management networks and
administrative systems.

Retest:
Confirm TCP 3389 is no longer reachable from the user segment and
remains accessible from the authorized management segment.

Part 54 — Example Validated Finding — Information Disclosure

Finding ID:
F-02

Title:
Service Banner Discloses Software Version

Severity:
Informational

Confidence:
High

Description:
The exposed SSH service provides product and version information
during initial protocol negotiation.

Impact:
The information may assist an attacker in technology
fingerprinting and vulnerability research.

Recommendation:
Review whether product version disclosure can be reduced without
affecting operational requirements.

Part 55 — Example False Positive

Scanner Finding:
Potential vulnerability associated with package version X.

Initial Severity:
High.

Validation:
Package information and the vendor security advisory confirm that
the distribution has backported the relevant security fix.

Classification:
False Positive.

Report Action:
Exclude from validated vulnerability totals.

Evidence:
Vendor package/advisory information retained in assessment notes.

Part 56 — Example Inconclusive Finding

Potential Issue:
Possible outdated database service.

Evidence:
Remote fingerprint indicates a potentially affected product family.

Limitation:
Exact package/build information could not be established and
credentialed verification was outside the available lab evidence.

Classification:
Inconclusive.

Recommendation:
Verify installed database build and patch status through an
authorized configuration review.

Part 57 — Create the Finding-to-Evidence Matrix

Finding	Scanner	Enumeration	Manual Validation	Config/Vendor Evidence
F-01	✓	✓	✓	✓
F-02	✓	✓	✓

This makes your findings defensible.

Part 58 — Create the Scanner Accuracy Summary

Record:

Total Scanner Alerts:

Validated Findings:

False Positives:

Inconclusive:

Informational Observations:

Validation Rate:

Do not treat the validation rate as a scanner quality score unless the methodology supports that conclusion.

Part 59 — Identify Duplicate Findings

Scanners may report several issues that represent one underlying problem.

Example:

TLS 1.0 Enabled

Weak Cipher Supported

Deprecated Cryptographic Configuration

You may decide to consolidate related items where appropriate.

Avoid artificially inflating finding counts.

Part 60 — Distinguish Root Cause and Symptom

Example:

Several unnecessary services exposed

may have a root cause:

Host firewall policy permits broad inbound access

Reporting the root cause may be more useful than many fragmented findings.

Part 61 — Prioritize Remediation

Create:

Priority	Finding	Why First
1		High impact + broad exposure
2		Management service
3		Configuration hardening

Use practical remediation order.

Part 62 — Build the Remediation Register

Finding	Recommendation	Owner	Retest Method
F-01	Restrict RDP	Network/Windows	Reachability test
F-02	Reduce banner	Linux	Re-enumerate

Part 63 — Create the Retest Register

For every finding:

Finding ID:

Original Evidence:

Expected Remediation:

Retest Technique:

Expected Secure Result:

Retest Status:
Pending

This prepares students for professional retesting.

Part 64 — Perform a Quality Review

Before accepting a finding, ask:

Is the asset correct?

Is the service correct?

Is the evidence current?

Is the version accurate?

Does the issue actually apply?

Was it safely validated?

Is there a compensating control?

Is severity justified?

Is confidence stated?

Can another tester reproduce it?

Is remediation actionable?

Part 65 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
Vulnerability Assessment & Finding Validation

Authorized Network:

Assessment Date:

Investigator:

Scanner:

Scanner Version:


TARGET 01

Hostname:

IP:

Services Assessed:

Scanner Alerts:

Potential Vulnerabilities:

Validated Findings:

False Positives:

Inconclusive Findings:


TARGET 02

Hostname:

IP:

Services Assessed:

Scanner Alerts:

Potential Vulnerabilities:

Validated Findings:

False Positives:

Inconclusive Findings:


HIGH-PRIORITY ISSUE 01

Asset:

Service:

Scanner Finding:

CVE:

CVSS:

Observed Version:

Vendor Context:

Affected Version Confirmed:
Yes / No / Unknown

Required Feature Present:
Yes / No / Unknown

Network Reachable:
Yes / No

Compensating Control:

Manual Validation:

Result:

Classification:

Severity:

Confidence:

Evidence:

Recommendation:

Retest:


HIGH-PRIORITY ISSUE 02

Asset:

Service:

Scanner Finding:

CVE:

Observed Version:

Manual Validation:

Classification:

Severity:

Confidence:

Recommendation:


FALSE POSITIVE

Scanner Finding:

Asset:

Reason Rejected:

Evidence:


INCONCLUSIVE ISSUE

Potential Finding:

Missing Evidence:

Why Inconclusive:

Recommended Follow-Up:


ASSESSMENT SUMMARY

Total Alerts:

Validated Vulnerabilities:

Potential Weaknesses:

False Positives:

Inconclusive:

Critical Findings:

High Findings:

Medium Findings:

Low Findings:

Informational:


FINAL ANALYSIS

Most Important Validated Finding:

Highest Confidence Finding:

Most Significant False Positive:

Largest Evidence Gap:

Most Important Compensating Control:

Are scanner results alone sufficient for final reporting?
No

Ready for Authentication & Remote Access Assessment:
Yes / No

Part 66 — What Not to Do

Do not:

Scan outside scope

Enable destructive vulnerability checks

Run denial-of-service plugins

Treat scanner severity as final severity

Treat every CVE match as applicable

Assume banner version equals exact patch state

Ignore vendor backports

Ignore configuration requirements

Ignore compensating controls

Launch exploits merely to prove scanner findings

Use proof-of-concept code unnecessarily

Guess credentials during validation

Modify target configuration

Hide false positives

Delete inconclusive results

Overstate impact

Report unsupported compromise scenarios as facts

Copy scanner text directly into the final pentest report

The professional rule is:

Validate the condition, not the scanner’s opinion.

Troubleshooting

Scanner Reports Hundreds of Findings

Start with:

exposed services
high-value assets
high-severity alerts
configuration issues you can validate safely

Deduplicate before analysis.

Scanner and Nmap Versions Differ

Record both.

Use stronger evidence such as:

package information
application output
vendor documentation

Do not choose whichever version creates the more severe finding.

Scanner Says CVE Applies but Manual Check Does Not

Investigate:

backported patches
disabled functionality
incorrect fingerprint
proxying
wrong OS/package context

The scanner may be wrong.

Service Is Potentially Vulnerable but Firewall Blocks It

Record the underlying software issue separately from current network exposure if appropriate.

The firewall is a compensating control.

Exact Patch Level Cannot Be Determined

Classify applicability as:

Unknown / Inconclusive

and recommend an authorized configuration review.

Evidence Requirements

Capture:

Evidence 01

Scope confirmation.

Evidence 02

Service inventory.

Evidence 03

Vulnerability scanner configuration.

Evidence 04

Raw scanner output.

Evidence 05

Scanner Findings Register.

Evidence 06

Assessment Priority Queue.

Evidence 07

Research Register.

Evidence 08

Vendor/CVE applicability evidence.

Evidence 09

Version validation.

Evidence 10

Applicability Matrix.

Evidence 11

Manual Validation Plan.

Evidence 12

Manual validation evidence.

Evidence 13

Compensating Control Register.

Evidence 14

False Positive Register.

Evidence 15

Inconclusive Register.

Evidence 16

Confidence Register.

Evidence 17

Risk Assessment Matrix.

Evidence 18

Validated Vulnerability Register.

Evidence 19

Finding-to-Evidence Matrix.

Evidence 20

Scanner Accuracy Summary.

Evidence 21

Remediation Register.

Evidence 22

Retest Register.

Evidence 23

Mission Challenge worksheet.

Mission Deliverables

Complete:

authorization revalidated
vulnerability scanner configured safely
destructive checks disabled
targets limited to authorized systems
raw scanner output preserved
scanner results triaged
high-priority findings identified
relevant CVEs researched
vendor advisories reviewed
product/version information validated
configuration applicability assessed
reachability validated
compensating controls documented
safe manual validation performed
false positives documented
inconclusive findings documented
severity assessed independently
confidence assigned
environmental context considered
validated findings written
evidence-to-finding mapping completed
remediation written
retest criteria defined
final Vulnerability Register completed
final report completed

Lab Report Template

# Lab 06 — Vulnerability Assessment & Finding Validation

## Executive Summary

## Mission Objective

## Authorization and Scope

## Target Inventory

## Service Inventory

## Vulnerability Assessment Methodology

## Scanner Configuration

## Scanner Results Summary

## Vulnerability Triage

## Research Methodology

## CVE and Vendor Advisory Analysis

## Version Validation

## Configuration Applicability

## Compensating Controls

## Manual Validation

## Validated Findings

### F-01
### F-02
### F-03

## False Positives

## Inconclusive Findings

## Confidence Assessment

## Severity and Risk Assessment

## Finding-to-Evidence Matrix

## Remediation Recommendations

## Retest Criteria

## Limitations

## Conclusion

Knowledge Check

Question 1 — Is a scanner alert automatically a vulnerability?

No.

It is an assessment lead that requires analysis and validation.

Question 2 — Does a CVE match prove the target is vulnerable?

No.

The affected product, version, configuration, and exposure must be verified.

Question 3 — Why can version matching produce false positives?

Because vendors may backport security fixes or customize packages without changing upstream-looking version strings.

Question 4 — What is a compensating control?

A control that reduces the practical exposure or impact of a weakness without necessarily removing the underlying condition.

Question 5 — Should you exploit every potential vulnerability to validate it?

No.

Use the least intrusive method that provides sufficient evidence.

Question 6 — What is the difference between severity and confidence?

Severity describes the importance or potential impact of the weakness. Confidence describes how certain you are that the finding is valid.

Question 7 — What should happen to a scanner false positive?

Document why it does not apply and retain the supporting validation evidence.

Question 8 — What should you do when evidence is insufficient?

Classify the issue as inconclusive and define the additional evidence required.

Question 9 — Does high CVSS always mean the highest organizational priority?

No.

Exposure, business importance, and compensating controls also matter.

Question 10 — What is the core principle of professional vulnerability assessment?

Scanner output identifies possibilities; validation determines findings.

Skills Achieved

After completing this lab, you should understand:

vulnerability assessment methodology
scanner configuration
vulnerability triage
CVE concepts
practical CVSS interpretation
vendor advisory review
version validation
backported-patch awareness
configuration applicability
manual validation
false-positive handling
inconclusive-result handling
compensating controls
severity assessment
confidence assessment
evidence quality
risk prioritization
remediation writing
retest planning
professional finding validation

Professional Takeaway

The weak workflow is:

Scanner
   ↓
Critical Alert
   ↓
Copy Into Report

The professional workflow is:

Scanner Alert
     ↓
Understand the Service
     ↓
Validate Technology
     ↓
Validate Version
     ↓
Validate Configuration
     ↓
Check Reachability
     ↓
Check Compensating Controls
     ↓
Safe Manual Validation
     ↓
Assess Impact
     ↓
Assign Confidence
     ↓
Write Finding

Always distinguish:

Scanner Alert
     ≠
Validated Finding

CVE Exists
     ≠
Target Is Affected

Old Version String
     ≠
Unpatched System

High CVSS
     ≠
Automatically High Business Risk

Potentially Vulnerable
     ≠
Exploitable From Your Position

Vulnerability Present
     ≠
Compromise Proven

By the end of this lab, you should be able to answer:

“Which observed weaknesses are genuinely present, what evidence proves them, how confident are we in the conclusion, and what should the organization fix first?”

What’s Next?

➡️ Lab 07 — Authentication & Remote Access Assessment

In the next lab, you will focus specifically on services that control access to systems.

You will assess:

SSH
RDP
web administration
remote management
supplied test accounts
authentication requirements
account lockout behavior
default or anonymous access where intentionally configured
transport protection
management-plane exposure
network restrictions
MFA awareness
evidence-based authentication findings

The methodology becomes:

Remote Service → Reachability → Authentication → Access Policy → Transport Security → Network Restriction → Evidence → Finding

The central question will be:

“Are the network’s remote-access and administrative services protected by appropriate authentication, encryption, and network access controls?”