Vulnerability Scanning Basics

You've mapped the network, discovered live hosts, and identified open ports — but you still don't know which of those services are actually exploitable. That's the gap this lesson fills. Vulnerability scanning is the step where you stop asking what's running and start asking what's wrong with it, turning raw reconnaissance into a prioritized list of weaknesses an attacker could weaponize. Without it, you're flying blind into an engagement; with it, you gain the clarity needed to move from discovery to exploitation ethically and efficiently.

The problem this lesson solves

Reconnaissance tells you that port 22 is open on a server, and port 443 is open on a web application. But open does not mean vulnerable, and vulnerable does not mean exploitable. The problem is that modern networks run dozens, even hundreds, of services — each with its own version, configuration, and patch level. Manually checking each one for known CVEs is tedious, error-prone, and completely impractical at scale.

Imagine walking into a building and finding every door unlocked, but having no idea which doors lead to the vault. Vulnerability scanning is the flashlight that reveals which doors are actually worth trying. It systematically compares what you've discovered against databases of known weaknesses — like the National Vulnerability Database (NVD) — and flags the ones that match. The result: a prioritized list of attack paths you can pursue (or patch, if you're on the defensive side).

Without scanning, you might spend hours chasing a dead end on an outdated service that's actually well-hardened, while a critical SQL injection sits unnoticed two ports away. The pain isn't just wasted time; it's false confidence — thinking you've done your due diligence when, in reality, you've only scratched the surface.

Core concept / mental model

Think of vulnerability scanning as reading the warning labels on everything you found during port scanning. If port scanning is like walking through a neighborhood and noting which houses have open windows, vulnerability scanning is like checking each window for a "Beware of Dog" sign — except the signs are hidden in databases, and the dog might be a remote code execution flaw.

At its heart, a vulnerability scanner does three things:

1. Identifies services and their versions (often by banner grabbing or fingerprinting).
2. Matches those fingerprints against a database of known vulnerabilities (e.g., CVEs).
3. Reports the matches with severity ratings (Critical, High, Medium, Low) and often with remediation advice.

Pro tip: Think of the scanner as a librarian, not a detective. It tells you which books on the shelf might contain harmful content (the CVEs), but it doesn't read the pages for you. Confirming exploitable behavior is the job of the next phase — exploitation.

Here's a simple visual model of the scanning pipeline:

Live hosts → Open ports/services → Version fingerprint → CVE lookup → Risk report

Each arrow is a step you'll practice in this lesson. The critical insight is that the quality of your scan depends on the accuracy of your fingerprints — a slightly wrong version number can mean missing a critical vulnerability entirely.

How it works step by step

Now let's trace the actual workflow of a vulnerability scan, from start to finish. While different tools have different interfaces, the underlying logic follows the same pattern.

Step 1: Define scope and get authorization

Before you run any scanner, you need written permission (like a penetration testing contract or a bug bounty scope). Scanning systems you don't own without authorization is illegal in most jurisdictions and violates the very ethics this track teaches. Always confirm the target IPs, domains, and time windows.

Step 2: Perform initial discovery

Use a tool like nmap to identify live hosts and open ports. This tells you where to scan next. For example, a simple ping sweep:

nmap -sn 192.168.1.0/24

This returns a list of responding hosts — the foundation for your scan.

Step 3: Enumerate services and versions

Now you need to know what is running on those hosts. Use version detection:

nmap -sV 192.168.1.10 -p 1-1000

This will show you service names, product names, and version numbers (e.g., Apache httpd 2.4.49). This fingerprint is what your vulnerability scanner will match against its database.

Step 4: Run the vulnerability scan

With your target list and service map, you can now employ a dedicated vulnerability scanner. For this lesson, we'll use Nessus (free tier) or OpenVAS (open-source), but the commands below focus on a CLI alternative, nmap with its NSE (Nmap Scripting Engine) scripts, which is perfect for learning.

Nmap includes scripts that check for specific vulnerabilities. For example, to check for the famous EternalBlue exploit (MS17-010) on a Windows host:

nmap --script vuln 192.168.1.10

Pro tip: The vuln script category runs a set of checks for known vulnerabilities. It's not as comprehensive as a dedicated scanner, but it's a great starting point for learning and for quick assessments.

Step 5: Analyze and prioritize

The scanner will produce a list of findings, each with:

• A CVSS score (0–10) indicating severity
• A description of the vulnerability
• Affected systems and ports
• Remediation steps (e.g., upgrade to version X)

Prioritize by criticality and exploitability — a critical RCE on a public-facing web server should jump to the top of your list, even if a medium issue affects more systems.

Hands-on walkthrough

Let's put this into practice with a safe, local environment. We'll scan a deliberately vulnerable machine, like Metasploitable 2, which you can run as a VM in VirtualBox. This gives you a realistic target with known vulnerabilities.

Step 1: Verify your target is up

ping -c 3 192.168.56.101

Replace the IP with your Metasploitable machine's address.

Step 2: Discover open ports

nmap -sV 192.168.56.101 -p- --min-rate 5000

Expected output (truncated):

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 ((Ubuntu) DAV/2)
445/tcp  open  netbios-ssn Samba smbd 3.0.20-Debian
3306/tcp open  mysql       MySQL 5.0.51a-3ubuntu5

Now you know which services you're up against — including a notoriously vulnerable vsftpd version.

Step 3: Run the vulnerability scan script

nmap --script vuln 192.168.56.101

Expected output (part of it):

PORT   STATE SERVICE
21/tcp open  ftp
| vulners: 
|   cpe:/a:vsftpd:vsftpd:2.3.4: 
|       CVE-2011-2523  7.5   https://vulners.com/cve/CVE-2011-2523
|_  
445/tcp open  netbios-ssn
| smb-vuln-ms17-010: 
|   VULNERABLE:
|   Remote Code Execution vulnerability in Microsoft SMBv1 servers

You'll see a list of known CVEs linked to the versions you discovered, complete with severity scores.

Step 4: Save and review your report

nmap --script vuln -oN vuln_report.txt 192.168.56.101

This saves your results to a text file for later analysis. Open it and inspect the details for each vulnerability — the description, the CVSS score, and any references.

Pro tip: Always store your scan results. Legal authorizations and client reports often require evidence of your findings.

Compare options / when to choose what

Not all vulnerability scanners are created equal. Here's a quick comparison to help you pick the right tool for the job:

When to choose what?

• Learning and quick checks: Start with Nmap's --script vuln. It's fast and helps you understand the underlying mechanics.
• Professional pentest reports: Nessus or OpenVAS give you more thorough reporting and compliance mapping.
• Continuous monitoring: Qualys (or similar) for ongoing assessments.

Variations to consider:

• Authenticated scans — These use valid credentials to scan deeper into the system (e.g., checking installed software versions, patch levels, and configurations) and reveal far more than unauthenticated scans.
• DAST (Dynamic Application Security Testing) — Tools like OWASP ZAP or Burp Suite focus on web applications, detecting flaws like SQLi and XSS using an active scanner.
• Compliance-driven scans — Scanning to meet standards like PCI-DSS often uses ASV-approved scanners (e.g., Qualys) with specific configuration templates.

Troubleshooting & edge cases

Vulnerability scanning rarely goes off without a hitch. Here are common issues and how to fix them:

Problem: No vulnerabilities found — is that real?

• False negatives are common, especially on older systems or when services aren't fully fingerprinted. Try an authenticated scan if you have credentials, or use multiple scanners to cross-check.
• Sometimes the target blocks certain probes (firewalls, IPS). Review your scan type; a -sV version detection might be incomplete.

Problem: Scan is extremely slow

• Targets with many ports or hosts can cause scans to take hours. Use --min-rate to speed up, but be aware it may cause missed ports or get you blocked.
• Consider port scanning first, then vulnerability scanning only on found ports.

Problem: False positives (reported vulnerabilities that don't actually exist)

• The scanner matches version numbers, but the server might be patched without updating the version string (backported patches). Verify manually — e.g., check the actual behavior or use proof-of-concept code.

Pro tip: Never base a pentest report solely on scanner output. Manual verification of high-severity findings is the difference between a professional and an amateur.

Problem: Scanner gets blocked or crashes

• Intrusion prevention systems (IPS) may drop your packets. Try scanning with a lower intensity (-T2 in Nmap) or use a different source IP if authorized.
• Ensure you have permission to scan; aggressive scanning can be seen as an attack.

What you learned & what's next

Let's recap what you've mastered in this lesson:

• The role of vulnerability scanning — You now understand it as the bridge between discovery and exploitation, giving you a prioritized list of weaknesses.
• The scanning workflow — From discovery and fingerprinting to CVE matching and reporting.
• Hands-on skills — You can run nmap --script vuln against a target, interpret the results, and save them for analysis.
• Decision-making — You know when to use quick scripts vs. comprehensive tools like Nessus or OpenVAS.
• Troubleshooting — You can handle false positives, slow scans, and scanner blocks.

Now that you can identify vulnerabilities, the natural next step is exploitation — learning how to use frameworks like Metasploit to confirm and leverage those weaknesses in a controlled, ethical manner. In the next lesson, you'll take the vulnerabilities you've discovered and turn them into proof-of-concept attacks, always within the bounds of your authorization.

Keep practicing on Metasploitable — the more you scan, the better you'll understand the landscape. See you there!