Vulnerability Scanning

You now know what is running. Vulnerability scanning is the automated search for known weaknesses in those services — cross-referencing what you found against a database of documented flaws and asking: does anything on this host match something that has been publicly exploited before?

Automated does not mean accurate

This is the lesson most people get wrong about vulnerability scanners. They run one, get back a list of findings colour-coded by severity, and treat that list as truth. It is not. It is a starting point. Vulnerability scanners are pattern-matching engines — they compare service banners and version numbers against known vulnerability signatures, but they cannot always tell the difference between a vulnerable configuration and a patched one that still reports the same version string.

The result is false positives — findings that look real but are not — and occasionally false negatives — vulnerabilities that exist but were not detected. Both are dangerous in a pen test context. False positives waste the client's remediation budget on things that do not need fixing. False negatives give the client a false sense of security about things that do.

Every vulnerability scanner finding needs manual validation before it goes into a report. That is not optional — it is the difference between a professional pen test and an automated scan report with a cover page on it.

Two types of scans — and when to use each

Vulnerability scanners operate in two fundamentally different modes. The choice between them is determined by what access you have been granted — not by which one produces more impressive results.

Nmap NSE as a lightweight vulnerability scanner

Before reaching for Nessus or OpenVAS, most pen testers run Nmap's scripting engine as a first pass. It is faster, produces less noise, and integrates naturally with the port and service data you already have. The --script=vuln category runs a curated set of checks across all open ports in a single pass.

You already saw this in Lesson 14 where it flagged the vsftpd backdoor and the Samba MS08-067 vulnerability. Here is a more targeted use — running specific vulnerability scripts against services of interest rather than the broad vuln category across everything.

The scenario: Your team lead has asked you to validate whether the web application on port 80 is vulnerable to any common web-level issues before the web testing phase begins. You run a targeted Nmap script check against the HTTP service specifically — faster than a full Nessus scan and focused on the attack surface you care about right now.

# Targeted Nmap vulnerability scripts against the web service on port 80
# Active recon — requires authorisation and open testing window

# --script=http-vuln-*  runs all scripts in the http vulnerability category
#   These check for specific known web server vulnerabilities
#   Each script targets a different CVE or vulnerability class

# --script=http-shellshock  checks for the Shellshock bash vulnerability (CVE-2014-6271)
#   Shellshock allowed remote code execution via CGI scripts on Apache servers
#   Still found on unpatched systems even a decade after disclosure

# --script=http-slowloris-check  checks for susceptibility to Slowloris DoS attacks
#   Slowloris holds connections open with incomplete requests to exhaust server threads
#   Apache 2.x without the reqtimeout module is particularly vulnerable

# -p 80  only scans port 80 — no need to rescan ports we already know about
nmap -sV --script=http-vuln-cve2010-2861,http-shellshock,http-slowloris-check \
  -p 80 192.168.56.101

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.2.8

| http-shellshock:
|   VULNERABLE:
|   HTTP Shellshock vulnerability
|     State: VULNERABLE (Exploitable)
|     IDs:  CVE:CVE-2014-6271
|       Web server has a CGI script that is vulnerable to shellshock.
|     Disclosure date: 2014-09-24
|     References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271

| http-slowloris-check:
|   VULNERABLE:
|   Slowloris DOS attack
|     State: LIKELY VULNERABLE
|     IDs:  CVE:CVE-2007-6750
|     Risk factor: High — an attacker may keep the web server down
|_    Solution: Apply mod_reqtimeout module or use a reverse proxy

Understanding CVSS scores — severity is not the same as priority

Every CVE entry carries a CVSS score — the Common Vulnerability Scoring System — which rates the severity of a vulnerability on a scale of 0 to 10. Vulnerability scanners use this score to colour-code findings: red for critical (9.0–10.0), orange for high (7.0–8.9), yellow for medium, blue for low.

Here is where people get caught out. A CVSS 9.8 vulnerability on a system that is not reachable from the internet is less urgent than a CVSS 6.5 vulnerability on the login page of a customer-facing web application. Severity measures the technical characteristics of the vulnerability in isolation — exploitability, impact, complexity. It does not factor in your specific environment.

In a pen test report, risk is always contextualised. A finding's priority in the report should reflect its real-world impact to the client — which means a pen tester adjusts the severity based on what they know about the target environment, not just what the scanner reported.

The "chain" point in the medium row is worth dwelling on. A medium-severity information disclosure finding — say, a server that reveals its internal IP address in error messages — combined with a separate medium-severity open redirect becomes a high-severity phishing enablement finding when chained. A scanner reports each one individually. A pen tester connects them.

Manual validation — the step that separates the report from the scan

Every significant finding from a vulnerability scanner needs to be confirmed manually before it appears in a client report. The method varies by finding type — for some, it means attempting the actual exploit in a controlled way. For others, it means verifying the configuration that makes the vulnerability possible. For banner-based findings, it means checking the patch level rather than relying on the version string alone.

The scenario: Your Nmap vuln scan flagged Shellshock as exploitable on the Apache CGI interface. Before writing it up as a confirmed critical finding, you manually trigger the vulnerability to confirm it is genuinely exploitable — not just present in theory. This is the validation step. You are checking whether the door actually opens, not just whether the lock looks old.

# Manual Shellshock validation using curl
# We inject a bash function definition into the User-Agent HTTP header
# If the server is vulnerable, bash will execute the injected command
# The () { :; }; payload is the Shellshock trigger — it defines a function
# then executes whatever comes after the closing brace

# This is active exploitation — only run within your authorised scope
# We use a harmless command (echo) to confirm execution without causing damage
# If the server returns "SHELLSHOCK_CONFIRMED" in the response body,
# the vulnerability is real and exploitable, not just present in version data

curl -H "User-Agent: () { :; }; echo Content-Type: text/html; echo; echo SHELLSHOCK_CONFIRMED" \
  http://192.168.56.101/cgi-bin/test.cgi

SHELLSHOCK_CONFIRMED

Building a validated findings list

After running automated scans and manually validating findings, the output is a structured list of confirmed vulnerabilities — each one with a status that records whether it was verified or remains unconfirmed. This is the document that drives the exploitation phase and eventually becomes the technical section of the final report.

Notice the Slowloris finding sits as "Unconfirmed" — not because the scanner was probably wrong, but because confirming a DoS vulnerability requires actually causing a denial of service. That requires explicit client approval before you attempt it. Running a DoS attack against a production web server without permission — even during an authorised pen test — can take down a live customer-facing service. Get sign-off first.

Practice questions

Quiz