Vulnerability Assessment

Why This Matters

VA is the foundation of most commercial pentest engagements — especially IVA, EVA, and ASV scans. Understanding the methodology, CVSS scoring, and how to handle tool output separates a professional report from a raw tool dump. Interviewers probe your understanding of CVSS constantly.

VA vs Penetration Test — The Real Distinction

A vulnerability assessment identifies weaknesses. A penetration test confirms they're exploitable and demonstrates impact. The distinction matters for two reasons:

Scope authorization: Your SOW defines which you're doing. Conducting exploitation during a VA-only engagement is out of scope.
Report accuracy: A VA report says "vulnerability identified" — a PT report says "vulnerability exploited, here's what we accessed." The client impact and remediation urgency differ.

In practice, many engagements are hybrid — vulnerability assessment with limited exploitation to confirm the highest-severity findings. Always clarify this in the pre-engagement phase.

CVSS v3.1 — Complete Reference

CVSS (Common Vulnerability Scoring System) v3.1 is the industry-standard severity scoring framework. Every significant CVE gets a CVSS score. Your reports should include CVSS scores with justification.

Base Score Metric Groups

CVSS base score has three groups: Exploitability, Scope, and Impact.

Exploitability Metrics

AV — Attack Vector (how the vulnerability is accessed):

Value	Score	Description	Example
Network (N)	0.85	Exploitable remotely over the internet	Web application SQLi
Adjacent (A)	0.62	Requires access to the same network/Bluetooth	ARP poisoning, VLAN hopping
Local (L)	0.55	Requires local access (logged-in user or physical)	Local privilege escalation via SUID binary
Physical (P)	0.20	Requires physical access to the device	Cold boot attack, evil maid

AC — Attack Complexity (conditions beyond attacker's control):

Value	Score	Description	Example
Low (L)	0.77	No special conditions required; attack is repeatable	Standard SQLi, missing auth
High (H)	0.44	Specific conditions must exist; not always achievable	Race condition requiring precise timing, MitM position required

PR — Privileges Required (what privileges the attacker needs):

Value	Score (Scope Unchanged)	Score (Scope Changed)	Description
None (N)	0.85	0.85	No prior authentication required
Low (L)	0.62	0.68	Regular user authentication required
High (H)	0.27	0.50	Admin-level authentication required

Note: Scope Changed gives a higher score for PR:Low and PR:High because with scope change, a privileged attacker can impact a wider set of components.

UI — User Interaction (victim must perform an action):

Value	Score	Description	Example
None (N)	0.85	No victim interaction required	Server-side vulnerabilities, unauthenticated RCE
Required (R)	0.62	Victim must take an action	XSS (victim visits page), phishing (victim clicks link)

Scope Metric

S — Scope (does impact extend beyond the vulnerable component?):

Value	Description	Example
Unchanged (U)	Impact limited to the vulnerable component	SQLi affecting only that database
Changed (C)	Impact can extend to other components	XSS in one app affecting admin panel of another; VM escape affecting hypervisor

Scope Changed is significant because it means one vulnerable component can compromise an entirely separate security authority.

Impact Metrics

These use the same three values: None (N) = 0.00, Low (L) = 0.22, High (H) = 0.56.

C — Confidentiality Impact: - None: No confidentiality impact

Low: Limited access to some information — attacker doesn't have full control of what is accessed
High: Total loss of confidentiality — all data within the component is accessible

I — Integrity Impact: - None: No integrity impact

Low: Attacker can modify some data but can't control which data is affected
High: Total loss of integrity — attacker can modify all data within the component

A — Availability Impact: - None: No availability impact

Low: Reduced performance or intermittent service interruption
High: Total loss of availability — attacker can fully deny service

Score Calculation

The base score formula is complex (involves an ISC sub-formula and exploitability sub-formula) — you don't need to memorize the math, but you need to understand the ranges:

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

Use the CVSS calculator: https://www.first.org/cvss/calculator/3.1

Temporal and Environmental Scores

Beyond the base score, CVSS has two optional modifier groups:

Temporal Score: Adjusts base score based on current exploit availability:

Exploit Code Maturity (E): Unproven → PoC → Functional → High
Remediation Level (RL): Official Fix → Temporary Fix → Workaround → Unavailable
Report Confidence (RC): Unknown → Reasonable → Confirmed

A CVSS 9.8 with no public exploit and a vendor patch available has a lower temporal score than the same vuln with a weaponized Metasploit module and no patch.

Environmental Score: Adjusts for the specific target environment — if the vulnerable component handles non-sensitive data (low confidentiality requirement), the effective score is lower. Use this when explaining why a high-CVSS vulnerability may be lower priority in a specific client's environment.

Common CVSS Scoring Examples

Unauthenticated remote SQLi allowing data extraction:

AV:N  — Network accessible
AC:L  — No special conditions
PR:N  — No authentication required
UI:N  — No user interaction needed
S:U   — Impact limited to the database
C:H   — All data extractable
I:H   — Data modifiable
A:L   — Some performance impact but not full DoS
→ Base Score: 9.4 (Critical)

Stored XSS in user profile (exploits admin):

AV:N  — Network accessible
AC:L  — No special conditions
PR:L  — Low privileges required (need account to post profile)
UI:R  — Admin must view profile
S:C   — XSS in user context, impacts admin session (different security domain)
C:L   — Some cookies/data accessible but not all admin data directly
I:L   — Can make some requests as admin
A:N   — No availability impact
→ Base Score: 5.4 (Medium)
→ Context: if XSS leads to account takeover of admin, effective severity is higher

Local privilege escalation via SUID binary:

AV:L  — Requires local access
AC:L  — No special conditions once on system
PR:L  — Need low-privilege shell to exploit
UI:N  — No user interaction
S:U   — Escalation within same host
C:H   — Root access = full confidentiality
I:H   — Root access = full integrity
A:H   — Root access = full availability
→ Base Score: 7.8 (High)

VA Methodology

Pre-Assessment

Receive and validate scope: Confirm IP ranges, domains, and applications from the client. Verify you can reach them (simple ping/traceroute). Note any exclusions.
Configure tools: Set up scan profiles appropriate for the environment — aggressive profiles on production systems can cause outages. Disable destructive checks.
Agree on testing window: Some organizations require VA scans during off-hours to minimize performance impact.
Credentials for authenticated scanning: For a comprehensive VA, you want credentials to scan authenticated application content. Request read-only accounts for web applications and OS-level credentials for host-based scanning.

Discovery Phase

Identify all live hosts in scope:

nmap -sn 192.168.0.0/24 -oA discovery
# Or
masscan -p0-65535 192.168.0.0/24 --rate=10000

Scanning Phase

Network-level scanning (Nessus/OpenVAS): Nessus and OpenVAS probe each host for:

Missing OS patches
Misconfigured services
Default credentials
Known software vulnerabilities
Compliance violations

# OpenVAS (open source)
gvm-start
# Access via https://localhost:9392
# Create a scan target → create a scan task → run

# Nessus (commercial, free for non-commercial)
# Access via https://localhost:8834
# New Scan → Advanced Scan → add targets → configure plugins → launch

Plugin categories in Nessus: - Local Checks: Requires credentials; scans OS patch level, installed software, configuration

Network Checks: No credentials; probe network services for known vulnerabilities
Compliance: Check against CIS benchmarks, PCI DSS, SOX

Authenticated vs unauthenticated scanning: - Unauthenticated: Only checks externally visible services. Misses 70%+ of vulnerabilities.

Authenticated (with credentials): Full OS-level check — patch state, configuration, installed software versions. Dramatically more findings. Always prefer authenticated scanning when authorized.

Web application scanning:

# Nikto
nikto -h http://target.com

# OWASP ZAP (both GUI and CLI)
zap-cli quick-scan -s all -r http://target.com

# Burp Suite Pro scanner
# Passive scanning (always on) + Active scanning (trigger per-endpoint)

# Nuclei (template-based, highly effective)
nuclei -u https://target.com -t cves/ -t exposures/ -t misconfiguration/
nuclei -l urls.txt -t cves/ -severity critical,high

Validation Phase

This is what separates a professional VA from a raw tool dump:

Tool output contains false positives — verify key findings manually before including them in your report.

Common false positives: - Nessus reports Apache 2.4.6 as vulnerable to CVE-X when the OS vendor has backported the fix

Scanner reports "directory traversal possible" based on path content, not actual traversal
SSL/TLS findings on internal services where the risk context differs

How to validate: - Cross-reference with vendor advisories — some vulnerabilities are platform-specific

Check if the OS vendor has backported patches (common with RHEL/CentOS/Debian)
Manually reproduce the vulnerability where possible
Look for version in response headers vs actual installed version (may differ)

Reporting Phase

Covered in depth in the Report Writing module. VA-specific points:

Group similar findings (e.g., "Missing critical patches on 15 hosts" as one finding with a list, not 15 separate findings)
Include CVSS score for each unique vulnerability
Distinguish confirmed from informational

False Positives and False Negatives

False Positive: Scanner reports a vulnerability that doesn't actually exist.

Risk: Report looks alarming, wastes client's remediation time, damages credibility
Cause: Version mismatch, backported patches, plugin errors, misconfigured scanner

False Negative: Scanner misses a vulnerability that does exist.

Risk: Client thinks they're safe when they're not
Cause: Scanning without credentials, unusual service configuration, zero-day or undisclosed vuln, scanner not updated

In interviews: Acknowledge both — a professional pentester validates tool output, doesn't just report it. "I cross-reference scanner findings with CVE databases and manually verify before including them in my report, because tools have false positive rates. I also supplement automated scanning with manual testing specifically to reduce false negatives."

Nessus Plugin Families — What to Know

Nessus organizes its checks into plugin families. Knowing the major ones signals depth:

Family	Description
Windows	Windows patch level, service configuration
Windows: Microsoft Bulletins	Specific MS security updates
Ubuntu Local Security Checks	Ubuntu patch state
Red Hat Local Security Checks	RHEL/CentOS patch state
Debian Local Security Checks	Debian/Ubuntu patch state
Web Servers	Apache, nginx, IIS vulnerabilities
Databases	Oracle, MSSQL, MySQL, PostgreSQL
Firewalls	Cisco, Juniper, Palo Alto checks
CGI abuses	Web application checks (SQLi, XSS, etc.)
SSL and TLS	Certificate and protocol checks
Default Unix Accounts	Default credential checks
Backdoors	Known backdoors and Trojans
Denial of Service	DoS vulnerability checks (typically disabled)
Settings	Plugin configuration meta-plugins

CVSS v3.1 — Worked Scoring Examples

The ability to justify a CVSS score in an interview or under client pushback is a professional skill. Here are complete worked examples.

Example 1 — Unauthenticated SQLi on Customer Portal

Vulnerability: SQL injection in login form, no authentication required
Database: MySQL with DBA privileges (xp_cmdshell equivalent possible)
System: Internet-facing customer portal

Scoring:
AV: Network (N) — exploitable over the internet
AC: Low (L) — no special conditions, standard web request
PR: None (N) — no login required
UI: None (N) — attacker acts alone
S: Changed (C) — DBA privilege allows OS command execution,
                   impacting systems beyond the web application
C: High (H) — all database data extractable + OS-level access
I: High (H) — data can be modified + OS files can be written
A: High (H) — database and server can be disrupted

Result: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H = 10.0 Critical

Example 2 — Stored XSS Affecting Other Users

Vulnerability: Stored XSS in comment field, executes in other users' browsers
Application: Internal project management tool
Impact: Steal session cookies → account takeover of other users

Scoring:
AV: Network (N) — exploitable remotely
AC: Low (L) — reliable, no special conditions
PR: Low (L) — requires a valid user account to post comment
UI: Required (R) — victim must view the comment page
S: Changed (C) — XSS executes in another user's browser (different security scope)
C: Low (L) — can steal cookies but not arbitrary data access
I: Low (L) — can perform actions as victim but limited scope
A: None (N) — no availability impact

Result: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N = 5.4 Medium

Context note: Despite CVSS 5.4, if the application is used by administrators
and XSS can steal admin sessions → contextual severity should be rated High

Example 3 — Local Privilege Escalation via SUID Binary

Vulnerability: Non-standard SUID binary allows arbitrary command execution
System: Linux server with SUID on 'vim'
Context: Attacker has low-privilege shell already

Scoring:
AV: Local (L) — requires existing local access (shell)
AC: Low (L) — straightforward exploitation once on system
PR: Low (L) — requires any low-privilege user account
UI: None (N) — no victim interaction
S: Unchanged (U) — escalation within the same host
C: High (H) — root access = all confidential data
I: High (H) — root access = modify any file
A: High (H) — root access = kill any process, fill disk

Result: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 7.8 High

Example 4 — IDOR Exposing PII

Vulnerability: GET /api/users/{id} accessible by any authenticated user
Data exposed: Name, email, phone number, address
User base: 50,000 customers

Scoring:
AV: Network (N) — exploitable remotely
AC: Low (L) — simple ID increment, reliable
PR: Low (L) — requires authenticated account (any user)
UI: None (N) — attacker acts alone
S: Unchanged (U) — impact within same application boundary
C: High (H) — all customer PII accessible
I: None (N) — read-only, no modification
A: None (N) — no availability impact

Result: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5 Medium

Context note: CVSS 6.5 Medium but contextual severity is High/Critical
given 50,000 records of PII with GDPR implications

Communicating CVSS in Client Conversations

Client says: "Why is this Medium? It seems serious."

CVSS measures the technical severity of the vulnerability itself in isolation. Contextual severity accounts for your specific environment. In this case, CVSS 6.5 reflects: requires authentication (PR:Low reduces the score), read-only impact (I:None), and no scope change. But the business impact — 50,000 customer PII records, GDPR notification obligation, regulatory fine exposure — elevates the business risk above what the base score suggests. Our report includes both the CVSS base score and our contextual severity assessment precisely because these situations arise.

Client says: "This CVE says 9.8 but you rated it High, not Critical."

The CVE's NVD score is the worst-case base score assuming the most vulnerable configuration. Your environment has compensating controls that reduce the exploitability: [network segmentation restricts access to this service / authentication is required that wasn't in the CVE's scoring / the service is on an isolated VLAN with no sensitive data]. The environmental score adjusted for your context is 7.2, which maps to High. I've documented the reasoning.

VA vs PT — Interview-Ready Distinction

Every VA interview tests whether you understand where your work fits in the assessment spectrum.

Scenario — interviewer asks: "You ran Nessus and it came back with 200 findings. Are you done?"

Wrong answer: "Yes, here's the report."

Right answer: "No. The scanner output is the starting point, not the deliverable. I need to:

Validate findings — eliminate false positives by manually checking high-severity issues. Nessus flags outdated Apache versions based on banner, but RHEL backports security fixes without version bumps. Manual verification checks the actual patch state.
Prioritize intelligently — not all CVSS 7.0 findings deserve the same priority. The one on the internet-facing authentication server is more urgent than the same finding on an isolated development box.
Contextualize — what's the actual impact in this specific environment? A MySQL root password accessible from outside is Critical. The same finding on a localhost-only development database is High at most.
Look for what scanners miss — scanners find known vulnerabilities in known products. They don't find business logic flaws, misconfigured authorization, or custom application vulnerabilities. For those, I need manual testing beyond the scan.
Produce a usable report — raw Nessus XML is not a deliverable. The report needs to be filtered, organized, deduplicated, and written so a developer can act on it."

Vulnerability Assessment Report Structure

A VA report differs from a pentest report — it's a compliance-oriented document:

1. Executive Summary (1 page)
   - Total findings by severity
   - Risk distribution chart
   - Key risk themes (patch gaps, access control, misconfigurations)
   - Top 5 most critical findings summary

2. Scope and Methodology (1 page)
   - IP ranges scanned
   - Date range
   - Tools used (Nessus, OpenVAS, manual validation)
   - Authenticated vs unauthenticated

3. Findings Summary Table
   ID | Title | Severity | Affected Hosts | Status
   ---|-------|----------|----------------|-------
   V-001 | EternalBlue (MS17-010) | Critical | 3 hosts | Open
   V-002 | Apache 2.2 EOL | High | 7 hosts | Open

4. Detailed Findings (one section per unique vulnerability)
   For grouped findings (same vuln on multiple hosts):
   - One write-up, list all affected hosts

5. Remediation Roadmap
   - Immediate (0-7 days): Critical
   - Short term (30 days): High
   - Medium term (90 days): Medium
   - Long term: Low

6. Appendices
   - Full Nessus/scanner output
   - Raw tool output