05 · Vulnerability Scanning¶

Vulnerability scanning is the systematic, automated process of identifying known weaknesses — missing patches, misconfigurations, outdated software — across a network or application before an attacker finds them first. This module covers the vulnerability management lifecycle and hands-on scanning with free, industry-standard tools.

Authorized targets only

Scan only hosts you own or a lab environment (Metasploitable2, a local VM you control). Port-scanning or vulnerability-scanning a network you don't have written authorization for is illegal in most jurisdictions, even if you find nothing.

1. The vulnerability management lifecycle¶

Discover assets → Scan for vulnerabilities → Prioritize by risk →
  Remediate/patch → Verify fix → Repeat on a schedule

Scanning is a process, not a one-time event — new CVEs are published daily, so a scan from six months ago tells you nothing about today's risk.

2. Asset discovery with Nmap¶

You can't scan what you don't know exists.

# Discover live hosts on a subnet (ICMP + ARP)
nmap -sn 192.168.56.0/24

# Full port scan with service/version detection on a discovered host
nmap -sV -p- 192.168.56.101

# OS detection + common scripts (safe, non-intrusive)
nmap -O -sC 192.168.56.101

PORT     STATE SERVICE VERSION
21/tcp   open  ftp     vsftpd 2.3.4
22/tcp   open  ssh     OpenSSH 4.7p1 Debian 8ubuntu1
80/tcp   open  http    Apache httpd 2.2.8
3306/tcp open  mysql   MySQL 5.0.51a-3ubuntu5

The version strings above (from a Metasploitable2 lab target) are exactly what a vulnerability scanner cross-references against known CVE databases.

3. Vulnerability scanning with OpenVAS/Greenbone¶

Greenbone Vulnerability Manager (GVM/OpenVAS) is the standard free, open-source vulnerability scanner, maintaining a continuously updated feed of tens of thousands of vulnerability tests (NVTs).

# Docker-based install (simplest path for a lab)
docker run -d -p 443:443 --name openvas greenbone/openvas-scanner

# Create a scan target and task via the web UI at https://127.0.0.1
# Target: your lab VM's IP
# Scan config: "Full and fast"

A scan produces findings ranked by CVSS score (0–10) with: - Summary of the vulnerability - Affected software/version - Impact if exploited - Solution (patch version, config change, or workaround) - CVE reference(s) for further research

4. Reading and prioritizing results¶

Not every "critical" finding deserves equal urgency. Prioritize using context, not just CVSS score alone:

Factor	Why it matters
CVSS base score	Theoretical severity in isolation
Exploit availability	Is there a public, working exploit (check Exploit-DB)?
Exposure	Internet-facing vs. internal-only, behind a firewall
Asset criticality	A critical vuln on a disposable test box ≠ one on the payment server
Compensating controls	Is it already mitigated by network segmentation, WAF, etc.?

This is why organizations use risk-based vulnerability management rather than "patch every CVSS 9+ immediately" — an internet-facing critical RCE with a public exploit is an emergency; the same CVSS score on an air-gapped internal test machine is a scheduled fix.

5. Credentialed vs. uncredentialed scanning¶

Uncredentialed scan: scanner probes from outside, like an attacker would --
  finds what's visible on the network (open ports, banner versions,
  known web app vulnerabilities). Misses anything requiring login.

Credentialed scan: scanner logs in with valid credentials and checks
  actual installed package versions, patch levels, and local
  misconfigurations directly -- far more accurate, finds far more.

Credentialed scanning is the industry standard for internal compliance scans (PCI-DSS, etc.) precisely because it reflects what a local attacker (or a compromised low-privilege account) could actually see.

6. Web application scanning¶

Nikto is a fast, free web server scanner good for a quick sanity check before deeper manual/proxy-based testing (Level 2 Module 2):

nikto -h http://192.168.56.101

+ Server: Apache/2.2.8 (Ubuntu) DAV/2
+ /phpinfo.php: Output from the phpinfo() function was found.
+ /phpMyAdmin/: phpMyAdmin directory found
+ OSVDB-3268: /icons/: Directory indexing found.

Each finding above is a real, fixable misconfiguration: phpinfo() left public leaks server internals; directory indexing exposes files never meant to be browsable.

7. From scan to remediation ticket¶

A scanner finding is only useful once it becomes a tracked, owned action:

Finding:      Apache 2.2.8 — multiple known CVEs, EOL since 2017
Asset:        web-01.internal (192.168.56.101)
CVSS:         9.8 (Critical) — CVE-2017-15715
Owner:        Web Platform team
Action:       Upgrade Apache to a supported 2.4.x release; retire EOL OS image
Due:          Per policy: Critical = 15 days, High = 30, Medium = 90
Verification: Re-scan after patch; close finding only once confirmed fixed

How It Actually Works: how a vulnerability scanner actually fingerprints a service and matches it to a CVE¶

Before a scanner like OpenVAS/Greenbone can tell you a host is vulnerable, it has to answer a narrower question first: exactly what software and version is listening on each open port. This is done by service fingerprinting — sending a sequence of protocol-specific probes and comparing the responses against a database of known signatures. For a web server, this might be as simple as reading the Server: HTTP header, but that's trivially spoofable, so real fingerprinting also uses subtler tells: the exact ordering and casing of response headers, how the server responds to a malformed request (different web servers return different error pages/behavior for the same malformed input), or for OS fingerprinting specifically, quirks in how a host's TCP/IP stack sets initial window size, TTL, and TCP option ordering in its SYN-ACK — these vary slightly across OS implementations because each vendor's network stack was written independently against the RFC, and RFCs leave several fields implementation-defined.

Once a scanner has a confident service+version match, it consults a local mirror of the National Vulnerability Database (NVD), which maps each version range to CVE IDs via structured CPE (Common Platform Enumeration) identifiers — a string like cpe:2.3:a:openssl:openssl:1.0.1:* names exactly "OpenSSL, version 1.0.1" in a machine-comparable form, and every CVE record lists which CPE ranges it affects. This is why a scan result can cite a specific CVE with a specific CVSS score without ever actually testing the vulnerability — most checks are this kind of version-based inference, which is fast and safe (it never touches the actual bug) but also why version-based scans routinely false-positive against backported security patches, where a vendor fixes a CVE in an older version number without bumping it (common in Linux distro packages) — the CPE match says vulnerable, the underlying code is not. Credentialed scanning sidesteps this specific weakness by logging into the host and reading the actual installed-package manifest (dpkg -l, the Windows registry's uninstall keys) instead of inferring version from network banners — a fundamentally more accurate data source, which is the concrete reason credentialed scans report both more true findings and fewer false positives than uncredentialed ones, not just "better because more thorough."

Key terms¶

Term	Meaning
CVE	Common Vulnerabilities and Exposures — a unique public ID for a known vulnerability
CVSS	Common Vulnerability Scoring System — standardized severity score
NVT	Network Vulnerability Test — a single check a scanner runs
Credentialed scan	Scan performed with valid login credentials for deeper visibility
False positive	A reported finding that isn't actually exploitable/present
Risk-based prioritization	Ranking fixes by real-world exploitability and exposure, not CVSS alone

Exercise¶

Stand up Metasploitable2 in a local VM (isolated, host-only network).
Run the Nmap discovery and full port scan commands above and record every open port and service version.
Install OpenVAS/GVM (or use an online free-tier scanner solely against your own lab VM) and run a full scan against Metasploitable2.
Pick the three highest-severity findings and write a remediation ticket for each, following the format in section 7.
Written answer: explain why a CVSS 9.8 finding on an internal, isolated lab VM might be prioritized differently than the identical finding on a production, internet-facing server.