Vulnerability Scanning

From Enumeration to Exploitation

So far we’ve been gathering information manually: what hosts exist, what ports are open, what services are running, what versions they are.

Vulnerability scanning takes all of that and asks one question:

Are any of these versions known to be broken?

How a Vulnerability Scanner Works

A scanner automates the entire recon pipeline and adds one critical step at the end: database matching.

The scanner doesn’t invent new vulnerabilities. It compares what it finds against a database of known issues.

• Detected Apache 2.4.49? Check the database.
• Found a match for CVE-2021-41773? Flag it.
• CVSS score is 9.8? Mark it Critical.

A scanner is only as good as its database. Miss an update, miss a vulnerability.

The CVE System

Every known vulnerability gets a unique identifier: a CVE (Common Vulnerabilities and Exposures).

The format is CVE-YEAR-NUMBER. Some real examples:

• CVE-2021-41773 - Apache path traversal
• CVE-2017-0144 - EternalBlue (SMB remote code execution)
• CVE-2021-3156 - Sudo heap overflow (local privilege escalation)

A CVE identifies what is broken. But it doesn’t tell you how bad it is.

That’s where CVSS comes in.

CVSS Scoring

CVSS (Common Vulnerability Scoring System) rates severity on a scale from 0 to 10:

A score of 9.8 typically means:

1. Anyone on the network can reach it
2. No credentials needed
3. No user interaction required
4. Full system compromise

That’s the kind of vulnerability you drop everything to fix.

Prioritize by severity. A Critical finding is your way in. A Low finding is background noise.

Types of Scans

By Location

External scans test from outside the network:

• What can an attacker on the internet see?
• Targets: DMZ systems, public web servers, internet-facing services
• Usually finds fewer vulnerabilities (firewalls, hardening)

Internal scans test from inside the network:

• What can an attacker do after breaching the perimeter?
• Targets: workstations, internal servers, domain controllers
• Usually finds far more vulnerabilities (less hardening internally)

By Authentication

Unauthenticated - no credentials, only finds what’s visible from outside:

• Open ports
• Exposed services
• Version-based matching

Authenticated - logs in with valid credentials, can check:

• Installed patches and updates
• Local configurations and permissions
• Installed software with exact version numbers
• Registry settings (Windows)

Authenticated scans are always more accurate. More findings, fewer false positives. If you have credentials, use them.

False Positives and False Negatives

No scanner is perfect. Results must be verified manually.

False Positive

The scanner says “vulnerable” but the system is actually patched.

This commonly happens with backporting. Linux distributions often fix a vulnerability but keep the old version number. The scanner sees “Apache 2.4.49” and panics, but the security patch was already applied.

False Negative

The scanner says “clean” but a real vulnerability exists.

This happens when:

• The scanner’s database is outdated
• The service doesn’t expose version information
• The vulnerability is a zero-day (not in any database yet)
• A custom application has bugs that no scanner knows about

Scanners find known vulnerabilities in known software. Custom applications, logic flaws, and zero-days require manual testing.

Vulnerability Scanning with Nmap

Commercial scanners like Nessus exist and are widely used in the industry. However, learning to use Nmap’s NSE as a lightweight vulnerability scanner is more valuable, since it works anywhere and teaches you what’s actually happening.

The vuln Category

Run all vulnerability detection scripts against a target:

sudo nmap -sV --script vuln 10.10.10.50

Target a specific port to speed things up:

sudo nmap -sV -p 443 --script vuln 10.10.10.50

This runs every NSE script categorized as vuln. It checks for known vulnerabilities based on detected service versions.

The vulners Script

The vulners script is especially powerful. It cross-references detected versions against the Vulners Vulnerability Database and returns:

• CVE numbers for every known vulnerability
• CVSS scores for severity ranking
• Links to exploits (marked with *EXPLOIT*)

sudo nmap -sV --script vulners 10.10.10.50

Entries marked *EXPLOIT* are your highest-priority findings. These have working proof-of-concept code available.

Custom NSE Scripts

For specific CVEs, you can find dedicated NSE scripts on GitHub. Search for the CVE number plus “nse”:

# Download and install the script
sudo cp http-vuln-cve2021-41773.nse /usr/share/nmap/scripts/

# Update the script database
sudo nmap --script-updatedb

# Run it against the target
sudo nmap -sV -p 443 --script http-vuln-cve2021-41773 10.10.10.50

The script will confirm whether the target is actually vulnerable, not just running a matching version.

Always review NSE scripts before running them. Scripts downloaded from the internet have full access to your system. A malicious script could backdoor your machine.

The Verification Mindset

A scanner gives you leads, not proof.

1. Scanner finds a CVE? Verify it manually before reporting
2. Scanner says “clean”? Don’t trust it blindly, test manually too
3. High CVSS score? Prioritize it, but confirm it’s exploitable
4. Version-based detection? Check for backporting before assuming

The scanner is a starting point, not the finish line. The best pentesters use scanners to save time, then verify everything by hand.