Skip to content
Lesson 5 of 8

Vulnerability Analysis

10 min read

What Vulnerability Analysis Is

Vulnerability analysis is the phase where you correlate the services and versions you discovered with known security weaknesses. It is the bridge between knowing what runs on a system and understanding what could go wrong. The goal is to build a prioritized list of real and relevant vulnerabilities, not an avalanche of noise.

This phase combines automated tools with human analysis. Scanners find candidates quickly, but the pentester validates each finding, discards false positives, and assesses the real impact in the client's context. Automation amplifies your reach, but professional judgment is what turns raw data into actionable findings.

A good vulnerability analysis distinguishes between the theoretically possible and the practically exploitable. A critical vulnerability behind several layers of mitigation may be less urgent than a medium one directly accessible from the internet.

Ethical framing: validate findings with judgment and without causing harm; a controlled proof of concept only when scope allows it.

Vulnerability Scanners

Vulnerability scanners automate detection by comparing systems against databases of known flaws. Nessus is one of the most widely used commercially: it offers deep scans, a broad plugin base, and detailed reports. OpenVAS (part of Greenbone) is its open-source alternative, very capable for network assessments.

For web applications and modern discovery, Nuclei has become enormously popular. It uses community-maintained YAML templates that describe how to detect specific vulnerabilities and misconfigurations. Its speed and the huge template library make it ideal for scanning many targets quickly and keeping up with recent flaws.

Each scanner has different strengths. Nessus and OpenVAS shine on network infrastructure; Nuclei stands out on web surface and targeted verification. Combining them gives broad coverage, always validating manually what they report.

Conceptual flow of an authorized scan

The workflow of a scanner like OpenVAS/Greenbone or Nessus always follows the same pattern: you define the target within scope, configure the scan policy, launch the task, and export the report for analysis. These commands are illustrative: they show the cycle, not an attack.

# Conceptual flow with Greenbone (OpenVAS) via its gvm-cli CLI.
# 1) Create a target restricted STRICTLY to the authorized scope
gvm-cli ... --xml '<create_target><name>client-scope</name><hosts>10.0.10.0/24</hosts></create_target>'

# 2) Create a task that pairs that target with a scan config
gvm-cli ... --xml '<create_task><name>quarterly-eval</name><target id="TARGET_ID"/><config id="CONFIG_ID"/></create_task>'

# 3) Launch the scan (only after confirming written authorization)
gvm-cli ... --xml '<start_task task_id="TASK_ID"/>'

# 4) Export the report for correlation and manual prioritization
gvm-cli ... --xml '<get_reports report_id="REPORT_ID" format_id="PDF"/>' > report.pdf

Nuclei tackles the web surface with community-versioned templates. Run it only against authorized targets and with rate control so you do not degrade the client's service.

# Scan with community templates, limited to one in-scope host.
# The cves/ templates verify known flaws without weaponizing exploits.
nuclei -u https://example.com -t cves/ -rate-limit 20 -o findings.txt

Correlating with Exploit-DB

Once you have identified a specific version, you can query public exploit databases to understand whether known code exists that confirms exploitability. searchsploit is a local Exploit-DB client you query offline. The goal here is correlation and validation, not launching anything: knowing that a flaw has a public exploit raises its real priority.

# Search public known entries for a specific version.
# Useful to correlate the scanner finding with documented exploits.
searchsploit apache 2.4.49

# View the detail and references of an entry (read-only for analysis)
searchsploit -x path/to/file.txt

The existence of a public exploit does not mean you should run it. It means the vulnerability is more likely to be leveraged in practice, a key input for prioritization.

Understanding CVEs

A CVE (Common Vulnerabilities and Exposures) is a unique identifier assigned to a publicly known vulnerability, with the format CVE-YEAR-NUMBER. The CVE system, maintained by MITRE, allows the entire industry to refer to the same flaw unambiguously. When a scanner reports a CVE, you can investigate exactly what it is, what it affects, and how to remediate it.

The NIST National Vulnerability Database (NVD) enriches each CVE with technical details, affected versions, references, and severity scores. Consulting the NVD or sources such as vendor advisories lets you understand the full context of a vulnerability before acting on it.

# Conceptual query to the NVD for a specific CVE (public API, read-only).
# Returns description, CVSS vector, affected versions, and references.
curl "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-41773"

Not all CVEs are equal or equally relevant. Some require very specific conditions to be exploited; others are trivial and widely leveraged. Part of the analysis is reading the CVE description with judgment and understanding whether the exploitation conditions are met in the environment you are assessing.

Anatomy of CVSS v3.1

The CVSS (Common Vulnerability Scoring System) is the standard for scoring the severity of a vulnerability on a scale of 0 to 10. It is organized into three metric groups: base (intrinsic, invariable characteristics of the flaw), temporal (how it evolves over time), and environmental (relevance to your specific environment). The score translates into categories: low, medium, high, and critical.

The CVSS vector encodes all metrics into a readable string. For example:

# Base vector of a critical vulnerability (scores 9.8/10).
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Each base metric describes one aspect of the flaw:

  • AV — Attack Vector (N=Network, A=Adjacent, L=Local, P=Physical): where it can be exploited from. N means network-accessible, the worst case.
  • AC — Attack Complexity (L=Low, H=High): how much effort or special conditions it requires. L means trivial.
  • PR — Privileges Required (N=None, L=Low, H=High): what level of access the attacker needs before exploiting.
  • UI — User Interaction (N=None, R=Required): whether a victim must do something (click, open a file).
  • S — Scope (U=Unchanged, C=Changed): whether the impact stays within the vulnerable component or escalates to others.
  • C / I / A — Confidentiality, Integrity, Availability (N=None, L=Low, H=High): the impact triad over data and service.

The temporal metrics adjust the score based on exploit maturity, remediation availability, and confidence in the report. The environmental metrics let you recompute severity according to the asset's criticality in your organization: a high-impact flaw on an isolated system with no sensitive data can be lowered, while one on an exposed production server can be raised.

CVSS gives you an objective starting point for prioritizing, but it is not the final word. A high-CVSS vulnerability that is only accessible from an isolated internal network may be less urgent than a medium-severity one exposed directly to the internet. As a pentester, your value lies in translating generic scores into concrete priorities for the client.

Modern Prioritization: EPSS and KEV

CVSS measures theoretical severity, but it does not predict whether a flaw will actually be exploited. Two modern inputs complete the picture:

  • EPSS (Exploit Prediction Scoring System), from FIRST, assigns each CVE a probability (from 0 to 1) that it will be exploited in the next 30 days, based on observed data of real activity. A high CVSS with low EPSS can wait; a medium CVSS with high EPSS deserves immediate attention.
  • CISA's KEV catalog (Known Exploited Vulnerabilities) lists the vulnerabilities known to be actively exploited in the real world. If a CVE is in the KEV, stop debating: it is top priority, regardless of its CVSS score.

Combining CVSS (severity) + EPSS (exploitation probability) + KEV (confirmed exploitation) produces a far more honest prioritization than any isolated metric. Prioritize what is in the KEV first, then high-EPSS items, and use CVSS to break ties according to the asset's context.

MITRE ATT&CK and Threat Modeling

Vulnerability analysis does not end at a list of CVEs: it feeds threat modeling. MITRE ATT&CK is a knowledge base of tactics and techniques used by real adversaries, organized by phases (initial access, execution, persistence, lateral movement, exfiltration, etc.).

Mapping your findings against ATT&CK turns loose vulnerabilities into coherent attack scenarios. For example, a vulnerable web service can be an initial access (TA0001) vector, which combined with weak credentials enables lateral movement. This framing helps the client understand not just what is broken, but how an attacker would chain the flaws to reach an objective. Threat modeling prioritizes complete attack paths, not isolated weaknesses.

False Positives and Validation

Automated scanners are prone to false positives: findings that the scanner marks as vulnerable but that actually are not, for example because the version was patched without changing the banner, or because a mitigation neutralizes the risk. Reporting false positives to the client damages your credibility and wastes their time.

That is why manual validation is indispensable. Before including a finding in the report, confirm that the vulnerability exists and is relevant in the real context. This may involve reviewing configurations, checking exact versions, or, when scope allows, a controlled proof of concept that demonstrates the problem without causing harm.

Validation also works in the other direction: scanners produce false negatives, missing real vulnerabilities. That is why human analysis always complements automation, looking for what the tools do not see, such as flawed business logic or chains of minor flaws that combined are critical.

Mini-scenario: ruling out a false positive

Suppose Nessus reports CVE-2021-41773 (path traversal in Apache 2.4.49) on an in-scope server. Before writing it up as critical, follow a validation flow that causes no harm:

  1. Confirm the exact version. The banner says Apache/2.4.49, but the system package may carry a security backport that fixes the flaw without changing the visible version number.
  2. Review the relevant configuration. The CVE only applies if the require all denied directive does not protect the directories and mod_cgi is enabled. If the client's config already mitigates those conditions, the finding is not exploitable.
  3. Cross-check with EPSS and KEV. This CVE is in fact in CISA's KEV, which raises its priority if it turns out to be real.
  4. Conclude with evidence. If the version is patched by backport, you document it as a false positive with the evidence (package manager output), and you do not report it as an active vulnerability.

That judgment, applied systematically, is what separates a trustworthy report from a scanner dump.

From Findings to Action

The product of this phase is a list of validated, prioritized, and documented vulnerabilities that feeds both the exploitation phase and the final report. Each entry should include the affected asset, the vulnerability, its severity, the evidence, and an impact hypothesis. This structure makes it easier to decide what to exploit and what to recommend remediating first.

Keep the analysis focused on what delivers real value. It is tempting to report every minor finding a scanner throws out, but a report saturated with low-priority noise dilutes the critical findings. Intelligent prioritization — supported by CVSS but guided by EPSS, the KEV, and context — is what distinguishes a professional analysis from an automatic dump of results.

Closing Checklist

Before considering the analysis phase complete, verify:

  • [ ] All scanned targets are within the authorized scope in writing.
  • [ ] Every scanner finding was manually validated and false positives discarded with evidence.
  • [ ] Every vulnerability has its CVE, CVSS vector, and severity category documented.
  • [ ] Prioritization cross-references CVSS + EPSS + KEV and the asset's real context.
  • [ ] Relevant findings are mapped to MITRE ATT&CK when it adds clarity to the attack scenario.
  • [ ] Each entry includes affected asset, evidence, and a reproducible impact hypothesis.
  • [ ] No proof of concept caused harm or exceeded the agreed scope.