"Lab 14 — Vulnerability Scanning and Assessment"

Mission Information

Item	Details
Lab	14
Lab Name	Vulnerability Scanning and Assessment
Track	CompTIA CySA+
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Role	Cybersecurity Analyst / Vulnerability Analyst
Environment	CySA+ Vulnerability Assessment Lab
Primary Systems	Analyst Workstation + Windows Endpoint + Linux Server
Primary Tools	Nmap + Vulnerability Scanner
Skills	Asset Discovery, Vulnerability Scanning, CVE Analysis, CVSS Interpretation, Finding Validation, False-Positive Analysis, Remediation Prioritization

Mission Scenario

You are working as a Cybersecurity Analyst at GHC Enterprise.

Your incident investigations have shown how compromised systems can affect the organization.

The security team now wants to take a more proactive approach.

Instead of waiting for an attacker to exploit weaknesses, you have been asked to identify vulnerabilities across the lab environment.

The systems in scope include:

CYSA-WIN01
10.10.10.20

CYSA-LINUX01
10.10.10.30

Your responsibility is to determine:

• which systems are reachable

• which services are exposed

• which software versions are visible

• which vulnerabilities are reported

• which findings are actually relevant

• which findings may be false positives

• which vulnerabilities should be fixed first

• whether remediation can be validated

Mission Objective: Perform a structured vulnerability assessment and turn raw scanner findings into validated, risk-based remediation recommendations.

Mission Objectives

By completing this lab, you will be able to:

• understand the vulnerability-management lifecycle

• define vulnerability-assessment scope

• perform asset discovery

• identify exposed ports and services

• understand authenticated vs unauthenticated scanning

• run a controlled vulnerability scan

• interpret scanner findings

• identify CVEs

• understand CVSS scoring

• distinguish severity from actual risk

• validate vulnerabilities manually

• identify potential false positives

• document evidence

• prioritize remediation

• perform basic remediation validation

• produce a vulnerability-assessment summary

1. Vulnerability Management vs Vulnerability Scanning

These terms are related but not identical.

Vulnerability Scanning

Assets
  ↓
Scanner
  ↓
Findings

The scanner identifies potential weaknesses.

Vulnerability Management

Discover Assets
      ↓
Scan
      ↓
Analyze
      ↓
Validate
      ↓
Prioritize
      ↓
Remediate
      ↓
Verify
      ↓
Repeat

A vulnerability scanner is therefore only one component of a broader security program.

2. What Is a Vulnerability?

A vulnerability is a weakness that may allow:

Unauthorized Access
Privilege Escalation
Information Disclosure
Service Disruption
Code Execution
Security Control Bypass

Vulnerabilities can originate from:

Missing Patches
Outdated Software
Weak Configuration
Exposed Services
Default Credentials
Insecure Protocols
Unsupported Systems
Application Flaws

3. Vulnerability Assessment Workflow

Use this workflow throughout the mission:

Define Scope
    ↓
Discover Assets
    ↓
Identify Services
    ↓
Run Scan
    ↓
Review Findings
    ↓
Validate Evidence
    ↓
Determine Risk
    ↓
Prioritize
    ↓
Remediate
    ↓
Rescan

Do not treat a scanner report as the final answer.

4. Lab Safety and Authorization

Only scan systems you own or are explicitly authorized to test.

For this lab:

Authorized Scope:

10.10.10.20
10.10.10.30

Do not scan:

Public Internet Hosts
Production Systems
Networks Outside the Lab
Third-Party Infrastructure

Some vulnerability scans can generate large numbers of connections and may affect unstable systems.

5. Start the Lab Environment

Start:

CYSA-ANALYST
10.10.10.10

CYSA-WIN01
10.10.10.20

CYSA-LINUX01
10.10.10.30

Optionally keep:

CYSA-SIEM
10.10.10.40

running if you want to observe scan activity in your security telemetry.

6. Create the Investigation Workspace

On CYSA-ANALYST:

mkdir -p ~/CySA-Lab/Investigations/LAB14/{Scans,Nmap,Evidence,Screenshots,Findings,Reports}

Create notes:

touch ~/CySA-Lab/Investigations/LAB14/investigation-notes.md

Use:

Assessment ID:
LAB14-VULN-001

7. Define the Assessment Scope

Document:

In Scope:
10.10.10.20
10.10.10.30

Assessment Type:
Internal Vulnerability Assessment

Scanner:
<selected scanner>

Assessment Window:
<date/time>

Also record systems that must not be scanned.

8. Build an Asset Inventory

Start with:

Asset	IP	OS	Role
CYSA-WIN01	10.10.10.20	Windows	Endpoint
CYSA-LINUX01	10.10.10.30	Ubuntu Linux	Server

Asset context becomes important later when prioritizing vulnerabilities.

9. Verify Host Availability

From CYSA-ANALYST:

ping -c 4 10.10.10.20

Then:

ping -c 4 10.10.10.30

If ICMP is blocked, do not automatically assume the system is offline.

Continue with authorized service discovery.

10. Perform Basic Host Discovery

Use Nmap against the lab subnet:

nmap -sn 10.10.10.0/24

Identify:

Live Hosts
IP Addresses
MAC Addresses where available

Compare discovered assets with your inventory.

Unexpected assets should be documented.

11. Perform Port Discovery

Scan the Linux server:

nmap 10.10.10.30

Scan Windows:

nmap 10.10.10.20

Record open ports.

Example:

Host	Port	State	Service
CYSA-LINUX01	22	Open	SSH
CYSA-WIN01	135	Open	RPC

Your actual results will differ.

12. Perform Service Version Detection

Run against your authorized hosts:

nmap -sV 10.10.10.30

And:

nmap -sV 10.10.10.20

Version detection can provide:

Service
Product
Version
Protocol

These details can help vulnerability scanners identify potential CVEs.

13. Save Nmap Evidence

Save Linux results:

nmap -sV 10.10.10.30 -oA ~/CySA-Lab/Investigations/LAB14/Nmap/linux-service-scan

Save Windows results:

nmap -sV 10.10.10.20 -oA ~/CySA-Lab/Investigations/LAB14/Nmap/windows-service-scan

The -oA option stores multiple output formats.

14. Analyze the Attack Surface

Review exposed services.

Ask:

Does this service need to be exposed?

Is the service expected?

Is the version supported?

Is the service encrypted?

Is administration externally reachable?

Could access be restricted?

Vulnerability management includes attack-surface reduction, not just patching.

15. Choose a Vulnerability Scanner

For the lab, you can use a vulnerability scanner such as:

Greenbone / OpenVAS
Nessus Essentials where licensed and permitted
Another approved vulnerability-management platform

The exact interface is less important than learning the assessment workflow.

16. Understand Scanner Components

A vulnerability scanner generally performs:

Host Discovery
      ↓
Port Discovery
      ↓
Service Detection
      ↓
Version Identification
      ↓
Configuration Checks
      ↓
Vulnerability Tests
      ↓
Finding Generation

Some checks depend only on network observations.

Others require credentials.

17. Unauthenticated Scanning

An unauthenticated scan examines the system from an external perspective.

It can identify:

Open Ports
Visible Services
Public Version Information
Network Configuration Issues
Some Remotely Detectable Vulnerabilities

It usually has limited visibility into:

Installed Packages
Patch State
Local Configuration
Registry Settings
Local Security Policies

18. Authenticated Scanning

Authenticated scans use authorized credentials to inspect the host more deeply.

This may provide:

Installed Software
Package Versions
Missing Patches
Local Configuration
Security Policies
Registry Values
File Permissions

Authenticated scanning generally provides more accurate host-level vulnerability information.

19. Understand Credential Safety

Never use:

Personal Accounts
Production Administrator Credentials
Shared Enterprise Passwords

inside training scanners.

Use dedicated lab credentials with only the permissions necessary for the exercise.

20. Create an Unauthenticated Scan

In your selected vulnerability scanner:

Scan Name:
LAB14-Uncredentialed

Targets:
10.10.10.20
10.10.10.30

Type:
Network Vulnerability Scan

Confirm the targets carefully before starting.

21. Start the Scan

Launch the assessment.

Observe:

Scanning
Host Discovery
Service Detection
Vulnerability Checks
Completion

Do not run unnecessary concurrent scans.

22. Review the Scan Summary

Once complete, review:

Hosts Scanned
Findings
Critical
High
Medium
Low
Informational

Record the totals.

Example:

Severity	Count
Critical	0
High	2
Medium	6
Low	10
Informational	18

Your results will vary significantly depending on the lab.

23. Understand Scanner Severity

Scanner severity is a useful prioritization signal.

But:

Scanner Severity
      ≠
Business Risk

A high-severity vulnerability on an isolated test machine may be less urgent than a medium-severity issue on a critical exposed production system.

24. Understand CVE

A vulnerability may have an identifier such as:

CVE-YYYY-NNNNN

CVE provides a standardized identifier for publicly disclosed vulnerabilities.

Record:

CVE ID
Affected Product
Affected Version
Vulnerability Description

25. Understand CVSS

CVSS stands for:

Common Vulnerability Scoring System

It provides a standardized severity score.

Typical ranges are:

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

Your scanner may use a particular CVSS version.

26. Do Not Use CVSS Alone

Consider:

CVSS
  +
Internet Exposure
  +
Asset Criticality
  +
Exploit Availability
  +
Threat Activity
  +
Security Controls
  +
Business Impact

Together these provide a better understanding of risk.

27. Select a High-Priority Finding

Choose one vulnerability reported against an authorized lab system.

Record:

Finding Name:
CVE:
CVSS:
Affected Host:
Port:
Service:
Scanner Evidence:

Do not attempt exploitation as part of this lab.

The focus is vulnerability assessment and validation.

28. Read the Scanner Evidence

Review exactly why the scanner produced the finding.

Evidence may include:

Detected Version
Service Banner
Package Version
Registry Value
Patch Information
Protocol Response
Configuration Value

Ask:

What evidence supports this vulnerability?

29. Validate the Exposed Service

If the finding relates to a network service, confirm the service:

nmap -sV -p <port> <target-ip>

Compare:

Scanner Result
     vs
Nmap Result

Do they identify the same product or service?

30. Validate Software Version on Linux

If authorized local access is available:

dpkg -l | grep <package>

or:

apt list --installed 2>/dev/null | grep <package>

For a service:

<service-command> --version

Use the appropriate command for the software being investigated.

31. Validate Software Version on Windows

On CYSA-WIN01, use appropriate local methods such as:

Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |
Select-Object DisplayName, DisplayVersion

You may also need to review:

Windows Update History
Installed Software
Feature Versions
Service Versions

depending on the finding.

32. Compare Installed Version with Vulnerability Conditions

Suppose the scanner reports:

Affected Versions:
1.0–1.5

Installed:
1.7

The scanner finding may be outdated or inaccurate.

Alternatively:

Affected:
Versions below 2.0

Installed:
1.4

supports the finding.

This is vulnerability validation.

33. Understand False Positives

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

Potential causes include:

Incorrect Version Detection
Backported Security Patches
Service Banner Mismatch
Scanner Logic Limitations
Incomplete Credential Access
Platform Identification Errors

34. Understand Backported Patches

Linux distributions sometimes patch a vulnerability without changing the upstream version in the way a scanner expects.

Therefore:

Version Looks Old

does not always mean:

Vulnerability Is Present

Package security advisories and vendor documentation may be required for validation.

35. Record Validation Status

Use:

Confirmed
Likely
Potential
False Positive
Unable to Validate

Example:

Finding	Scanner	Validation
Vulnerability A	High	Confirmed
Vulnerability B	Medium	False Positive
Vulnerability C	High	Unable to Validate

36. Investigate Missing Patches

Review findings related to:

Operating System Updates
Security Updates
Application Patches
Library Updates

Ask:

Is the patch installed?
Is a reboot required?
Is the vulnerable service still running?
Is the affected software actually used?

37. Investigate Unsupported Software

A scanner may identify:

End-of-Life Operating System
Unsupported Application Version
Deprecated Service

These can be particularly important because:

No Security Updates
      ↓
Persistent Exposure

38. Investigate Insecure Protocols

Findings may identify:

Cleartext Protocols
Legacy TLS Versions
Weak Ciphers
Insecure Authentication Methods

For example, a service may work correctly but still expose sensitive traffic using an insecure protocol.

39. Investigate Default or Weak Configurations

Potential findings include:

Default Accounts
Anonymous Access
Directory Listing
Unnecessary Administrative Interfaces
Excessive Permissions
Weak Cryptographic Settings

Configuration vulnerabilities can be just as important as missing patches.

40. Compare Authenticated and Unauthenticated Results

If resources permit, configure a credentialed scan of your own lab systems.

Then compare:

Capability	Unauthenticated	Authenticated
Open ports	✓	✓
Visible services	✓	✓
Installed packages	Limited	✓
Missing local patches	Limited	✓
Local configuration	Limited	✓
Patch validation	Limited	Better

Document what additional findings appear.

41. Why Credentialed Scans Often Improve Accuracy

Authenticated scanning can reduce reliance on:

Network Banners
Version Guessing
Remote Fingerprinting

and inspect the actual host state.

This can reduce both:

False Positives
False Negatives

depending on configuration.

42. Prioritize Findings by Risk

Create an initial prioritization model:

Technical Severity
      +
Exploitability
      +
Exposure
      +
Asset Criticality
      +
Threat Context
      =
Remediation Priority

Later, Lab 15 will expand this using CVSS, EPSS, and threat intelligence.

43. Identify Internet or Network Exposure

For each finding, determine:

Is the port open?
Is the service reachable?
Which network can reach it?
Is authentication required?
Can firewall rules restrict access?

A vulnerability that cannot be reached may represent lower immediate risk than an exposed weakness.

44. Consider Asset Criticality

Suppose the same vulnerability exists on:

Development Workstation

and:

Identity Server

The technical vulnerability may be identical.

The business risk may not be.

45. Consider Known Exploitation

A vulnerability with:

Public Exploit
Active Exploitation
Threat Actor Usage

may require faster remediation.

Do not download or run exploit code in this lab.

Use approved intelligence sources for context.

46. Create the Vulnerability Register

Build:

ID	Asset	Finding	CVE	CVSS	Validation	Priority
VULN-001	CYSA-LINUX01	<finding>	<CVE>	8.1	Confirmed	High
VULN-002	CYSA-WIN01	<finding>	<CVE>	6.5	Confirmed	Medium

Add:

Port
Service
Evidence
Remediation
Owner
Status

if desired.

47. Recommend Remediation

Common remediation strategies include:

Patch
Upgrade
Remove Software
Disable Service
Restrict Network Access
Change Configuration
Implement Compensating Control
Replace Unsupported Technology

Be specific.

Instead of:

Fix vulnerability.

write:

Upgrade the affected package to the vendor-supported security release and restrict access to the service until remediation is complete.

48. Understand Compensating Controls

Sometimes immediate patching is not possible.

Temporary controls may include:

Firewall Restriction
Network Segmentation
Disable Feature
Remove Internet Exposure
EDR Detection
Application Allowlisting
Enhanced Monitoring

Compensating controls reduce risk but do not necessarily eliminate the underlying vulnerability.

49. Remediate a Safe Lab Finding

Choose one safe, straightforward finding.

Examples:

Install Available Security Update
Disable an Unnecessary Service
Update an Outdated Package
Restrict an Unneeded Port

Document the state before making the change.

50. Apply Remediation

For a Linux package, depending on your finding:

sudo apt update

Then upgrade the relevant supported package according to your environment.

For Windows, use the appropriate Windows Update or approved software-update process.

Do not blindly update packages unrelated to your selected finding.

51. Record Change Evidence

Document:

Finding
Original Version / Configuration
Remediation Applied
New Version / Configuration
Time
Analyst

This provides an audit trail.

52. Rescan the Finding

Run a targeted rescan against the remediated host.

Your goal is:

Finding
   ↓
Remediation
   ↓
Rescan
   ↓
No Longer Detected

If the scanner still reports it:

Validate Again
Check Reboot Requirement
Review Scanner Evidence
Verify Updated Version

53. Understand Vulnerability Status

Use lifecycle states such as:

Open
Validated
Remediation Planned
Remediated
Risk Accepted
False Positive
Closed

This helps organizations track vulnerabilities beyond the initial scan.

54. Search SIEM for Scan Activity

If your SIEM, Zeek, or Suricata is running, search for:

10.10.10.10

You may observe:

Many TCP Connections
Multiple Destination Ports
IDS Alerts
Connection Failures

This demonstrates an important SOC challenge:

Authorized vulnerability scanning can resemble reconnaissance.

55. Differentiate Authorized Scanning from Malicious Reconnaissance

A SOC analyst should verify:

Known Scanner IP?
Approved Assessment Window?
Authorized Ticket?
Expected Targets?
Known Security Team Activity?

This context prevents unnecessary incident escalation.

56. Build a Vulnerability Timeline

Example:

Time	Activity
10:00	Assessment started
10:05	Asset discovery completed
10:15	Vulnerability scan started
10:45	Scan completed
11:00	High finding validated
11:30	Remediation applied
12:00	Verification scan completed

A timeline provides evidence of assessment and remediation activities.

57. Build a Vulnerability Finding Record

Use:

## VULN-001

### Asset

CYSA-LINUX01

### Finding

<finding name>

### CVE

<CVE ID>

### CVSS

<score>

### Affected Service

<service / port>

### Scanner Evidence

<evidence>

### Validation

Confirmed / Likely / False Positive / Unable to Validate

### Risk

Explain:
- exposure
- exploitability
- asset importance
- likely impact

### Remediation

Document recommended action.

### Verification

Document rescan result.

### Status

Open / Remediated / Closed

58. Mission Challenge — Vulnerability Assessment

The security manager asks:

Identify the most important vulnerabilities across CYSA-WIN01 and CYSA-LINUX01 and recommend what should be remediated first.

Using your scan data, determine:

1. Which assets were discovered?

2. Which ports are exposed?

3. Which services are running?

4. Which software versions were identified?

5. How many findings exist by severity?

6. Which critical/high findings were reported?

7. Which CVEs are associated?

8. What are their CVSS scores?

9. What evidence supports each finding?

10. Which findings were validated?

11. Were any false positives identified?

12. Are vulnerable services reachable?

13. Are affected systems business-critical?

14. Are patches available?

15. Are any services unnecessary?

16. Can network exposure be reduced?

17. Which vulnerability should be remediated first?

18. What compensating controls are appropriate?

19. Was remediation applied?

20. Did the verification scan confirm the fix?

59. Document Your Findings

Update:

~/CySA-Lab/Investigations/LAB14/investigation-notes.md

Use:

# LAB14 Vulnerability Assessment

## Assessment ID

LAB14-VULN-001

## Scope

- CYSA-WIN01
- CYSA-LINUX01

## Asset Discovery

Document discovered assets.

## Service Discovery

Document:
- host
- port
- protocol
- service
- version

## Scan Summary

Document:
- Critical
- High
- Medium
- Low
- Informational

## High-Priority Findings

For each finding document:
- asset
- vulnerability
- CVE
- CVSS
- port/service
- scanner evidence

## Validation

Classify each important finding:
- Confirmed
- Likely
- False Positive
- Unable to Validate

## Risk Context

Document:
- exploitability
- network exposure
- asset criticality
- potential impact

## Remediation

Document recommended remediation.

## Verification

Document results of the rescan.

## Final Priority

Identify which vulnerabilities should be addressed first and explain why.

60. Example Analyst Findings

A lab assessment might resemble:

Assessment:
LAB14-VULN-001

Assets Assessed:
CYSA-WIN01
CYSA-LINUX01

Finding Summary:
Several low and medium findings and one higher-priority vulnerability were identified.

Highest-Priority Finding:
Outdated network-facing service with a known security issue.

Validation:
Affected version was confirmed locally.

Exposure:
Service was reachable from the lab network.

Risk:
Elevated because the vulnerable service was network-accessible.

Recommended Action:
Upgrade to the supported patched version and restrict network access where the service is not required.

Remediation:
Security update applied.

Verification:
Targeted rescan no longer reported the vulnerability.

Status:
Closed

Assessment:
Validated vulnerability successfully remediated in the controlled laboratory.

61. Evidence to Capture

Capture:

01-assessment-scope.png
02-host-discovery.png
03-linux-port-scan.png
04-windows-port-scan.png
05-service-version-scan.png
06-vulnerability-scan-config.png
07-scan-summary.png
08-high-severity-findings.png
09-cve-details.png
10-cvss-score.png
11-scanner-evidence.png
12-version-validation.png
13-false-positive-analysis.png
14-authenticated-scan.png
15-vulnerability-register.png
16-remediation-action.png
17-rescan-result.png
18-siem-scan-telemetry.png
19-vulnerability-timeline.png
20-final-findings.png

62. Validation Checklist

• Authorized assessment scope was documented

• Asset inventory was reviewed

• Host discovery was performed

• Open ports were identified

• Service versions were investigated

• Nmap evidence was saved

• Vulnerability scanner was configured

• Unauthenticated scan was completed

• Scan summary was reviewed

• Critical/high findings were investigated

• CVE identifiers were reviewed

• CVSS scores were interpreted

• Scanner evidence was reviewed

• At least one finding was manually validated

• False-positive concepts were applied

• Software/package versions were verified

• Missing-patch findings were investigated

• Unsupported software was considered

• Insecure services/configurations were reviewed

• Authenticated vs unauthenticated scanning was understood

• Risk context was added to scanner severity

• Exposure was considered

• Asset criticality was considered

• Vulnerability register was created

• Remediation recommendation was documented

• One safe remediation was performed where applicable

• Verification rescan was completed

• Finding lifecycle status was assigned

• SIEM scan telemetry was reviewed where available

• Evidence was captured

• Final findings were documented

63. Mission Review

In this mission, you shifted from reactive incident investigation to proactive vulnerability management.

You followed:

Assets
  ↓
Discovery
  ↓
Services
  ↓
Vulnerability Scan
  ↓
Scanner Findings
  ↓
Validation
  ↓
Risk Context
  ↓
Prioritization
  ↓
Remediation
  ↓
Verification

The most important lesson is:

A scanner finding is not the same thing as a validated vulnerability, and a CVSS score is not the same thing as organizational risk.

A strong analyst combines:

Scanner Evidence
      +
Validation
      +
CVSS
      +
Exposure
      +
Asset Criticality
      +
Threat Context
      =
Useful Remediation Priority

Skills Developed

After completing this mission, you should be able to:

• define vulnerability-assessment scope

• discover assets

• identify exposed services

• perform service-version detection

• understand vulnerability-scanner architecture

• perform unauthenticated vulnerability scans

• understand authenticated scanning

• interpret vulnerability findings

• identify CVEs

• interpret CVSS scores

• validate scanner findings

• recognize false positives

• assess network exposure

• consider asset criticality

• create vulnerability registers

• recommend remediation

• apply compensating controls

• validate remediation using rescans

• distinguish authorized scanning from malicious reconnaissance

• document vulnerability-assessment findings

What’s Next?

Lab 15 — Vulnerability Prioritization with CVSS, EPSS and Threat Intelligence

You now know how to discover and validate vulnerabilities.

The next challenge is deciding:

Which vulnerability should we fix first?

Organizations may have hundreds or thousands of findings.

Prioritizing solely by scanner severity can result in:

Too Many Critical Findings
        ↓
Limited Remediation Capacity
        ↓
Poor Prioritization

In the next mission, you will enrich vulnerability findings with:

• CVSS

• EPSS

• exploit availability

• active exploitation

• CISA KEV concepts

• threat intelligence

• asset criticality

• exposure

• compensating controls

• business impact

• remediation effort

• risk-based prioritization

The workflow evolves from:

Vulnerability Finding
      ↓
CVSS Severity

to:

Vulnerability
      +
Exploit Probability
      +
Threat Intelligence
      +
Exposure
      +
Asset Criticality
      =
Remediation Priority

➡️ Next: Lab 15 — Vulnerability Prioritization with CVSS, EPSS and Threat Intelligence