Vulnerability Scanning Concepts and Scan Types

Vulnerability scanning matches hosts and applications against known weakness signatures—outdated software, unsafe configurations, or plugin checks. A scanner reports a candidate issue; you still validate reachability, business impact, and exploitability before you treat it as a confirmed finding.

PenTest+ expects you to distinguish scan categories that answer different questions: where the scan runs (internal versus external), whether credentials are used (authenticated versus unauthenticated), how the target is inspected (network versus host), and—separately—how application code is tested (SAST, DAST, IAST, SCA). Short lab demos on Metasploitable 2 show unauthenticated network and web scans from Kali.

Vulnerability scanning vs assessment vs penetration testing

These terms overlap in conversation but mean different depths of work:

A scanner might flag “Apache 2.2.8 appears outdated.” Assessment asks whether that service is exposed on a path you care about and whether compensating controls exist. Penetration testing goes further—proving an attacker could abuse the weakness in your environment.

On Linux, do not judge vulnerability status from the upstream version string alone. Distributions often backport security fixes while retaining an older-looking package version, so scanner version matches need vendor advisory cross-checks—not only CVE text.

Vulnerability scan types at a glance

Infrastructure vulnerability scanning uses several independent axes. They are not interchangeable labels:

Use network reconnaissance with Nmap when you still need live hosts and open ports. Vulnerability scanning layers on top of that map.

Internal vs external vulnerability scanning

Internal and external describe where the scan originates—not whether credentials are used.

An internal scan can still be unauthenticated—your scanner might probe SMB on 10.0.0.0/8 without logging in. An internal authenticated scan, by contrast, can read installed packages and local policy settings that no remote port banner reveals.

External plus unauthenticated modeling is what the Nmap and Nikto demos below represent: Kali on a lab network probing Metasploitable without credentials.

Authenticated vs unauthenticated vulnerability scanning

On an engagement, credentialed scanning uses RoE-supplied accounts. The engine logs in remotely—SSH on Linux, SMB or WinRM on Windows—and compares inventories to CVE feeds. That is different from installing a permanent agent on the endpoint.

Authenticated does not automatically mean complete. Credentialed scan depth depends on the supplied account. A low-privilege login may expose package information on Linux but still miss protected registry, patch, or configuration data on Windows.

The Nikto demo later shows Apache 2.2.8 is reachable without credentials. A credentialed host scan could add whether other packages share the same patch gap and whether local baselines fail compliance checks.

Network, host, and agent-based scanning

Network scans scale across subnets quickly. Host/local assessment sees installed software and configuration that never appears on a port banner. Agent-based tools suit continuous monitoring; credentialed remote scans suit periodic assessment windows.

Run an unauthenticated network vulnerability scan

Export your lab target once per shell session. Replace the IP if your lease differs:

TARGET=192.168.56.127
LAB=/tmp/vuln-scan-lab
mkdir -p "$LAB"

An unauthenticated network scan probes services from Kali without logging into the target. It mirrors an external attacker who only has network reachability.

Run a targeted SMB vulnerability script against Metasploitable port 445:

nmap -Pn -p445 --script smb-vuln-ms10-061,smb-vuln-ms17-010 "$TARGET"

Sample output:

Starting Nmap 7.99 ( https://nmap.org ) at 2026-08-31 10:08 -0700
Nmap scan report for 192.168.56.127
Host is up (0.0012s latency).

PORT    STATE SERVICE
445/tcp open  microsoft-ds

Host script results:
|_smb-vuln-ms10-061: false

Nmap done: 1 IP address (1 host up) scanned in 1.43 seconds

The script checked for a known SMB print-spooler flaw and reported false on this lab image. That is still useful evidence: the check ran, and the host did not match that signature. Scanning does not mean every test finds a vulnerability. Broader categories such as --script vuln exist, but they run longer and are noisier—match script choice to RoE time and scope. See Nmap NSE scripts for category selection.

Run an unauthenticated web vulnerability scan

DAST-style tools test a running application from the outside without source code. Nikto is useful here as a lightweight external web-server vulnerability scanner. Full DAST platforms such as OWASP ZAP or Burp Suite analyze broader application paths, parameters, and workflows—not just server banners and known risky files.

Cap runtime so a lab sweep does not run for an hour:

nikto -h "http://${TARGET}/" -maxtime 45s -o "$LAB/nikto.txt" -Format txt

Sample output (trimmed):

+ Server: Apache/2.2.8 (Ubuntu) DAV/2
+ Apache/2.2.8 appears to be outdated (current is at least 2.4.66).
+ PHP/5.2.4-2ubuntu5.10 appears to be outdated (current is at least 8.5.1).
+ /: Suggested security header missing: x-content-type-options.
+ /: HTTP TRACE method is active and replies which suggests the host is vulnerable to XST.
+ /phpinfo.php: Output from the phpinfo() function was found.

Nikto flagged outdated Apache and PHP builds, missing security headers, and an exposed phpinfo.php page. The “current is at least” version text comes from Nikto's local plugin database and may change after updates—treat it as a lead, not a universal current-version fact.

Confirm manually before you call any line a reportable finding. WordPress-specific coverage belongs in WPScan, not a generic Nikto pass.

Scan timing, intensity, and "stealth"

Scan intensity controls probe rate and timing. Nmap labels -T0 through -T5 as timing templates; lower values send fewer packets per second. That can reduce how quickly a scan trips rate-based thresholds—but it is not invisibility.

Compare aggressive versus polite timing on one authorized port:

nmap -Pn -p80 -T4 "$TARGET"

Sample output:

Nmap scan report for 192.168.56.127
Host is up (0.0012s latency).
PORT   STATE SERVICE
80/tcp open  http
Nmap done: 1 IP address (1 host up) scanned in 1.29 seconds

Run the same check with a slower template:

nmap -Pn -p80 -T2 "$TARGET"

Sample output:

Nmap scan report for 192.168.56.127
Host is up (0.0012s latency).
PORT   STATE SERVICE
80/tcp open  http
Nmap done: 1 IP address (1 host up) scanned in 3.78 seconds

Same open port—the slower template took longer because Nmap waited between probes. Other scan-control options include SYN scanning (-sS with sudo), narrower port lists, --scan-delay, and explicit rate limits. SYN scans are sometimes historically called “stealth scans,” but modern IDS and firewalls still detect them. Match intensity to the RoE.

SAST, DAST, IAST, and SCA

Application security testing uses a separate taxonomy from infrastructure vulnerability scans. These models answer how code and dependencies are inspected—not where the scanner sits on the network.

SAST (Static Application Security Testing)

SAST analyzes source code or bytecode without running the app. It runs in CI pipelines and finds patterns such as hard-coded secrets, unsafe functions, or SQL strings built from user input.

• Runs before deploy
• Can produce false positives that require developer or security triage
• Examples: Bandit (Python), Semgrep, SonarQube

DAST (Dynamic Application Security Testing)

DAST tests the running application from the outside. OWASP describes DAST tools as web application scanners that exercise live HTTP paths against a deployed build.

• No source code required
• May miss dead code paths never reachable in the test crawl
• Examples: OWASP ZAP, Burp Suite active scanning; Nikto for lighter server-focused checks

IAST (Interactive Application Security Testing)

IAST combines runtime monitoring with code instrumentation. An agent watches live requests and maps flaws to source lines when a dangerous sink executes during testing.

• Runtime context can improve confidence for exercised code paths
• Requires agent install and purposeful test traffic
• Common in enterprise SDLC pipelines

SCA (Software Composition Analysis)

SCA scans dependency manifests and lockfiles for known vulnerable third-party components. OWASP frames SCA around vulnerabilities in libraries your application imports—not your own source lines.

• Critical for supply-chain risk
• Examples: npm audit, pip-audit
• Tools such as Trivy can also inspect container images, including OS packages, application dependencies, and image misconfigurations beyond pure manifest SCA

Compliance / configuration scanning

Compliance scanning checks a host against a security baseline or standard such as CIS rather than only matching CVE signatures. Results may include password-policy failures, unnecessary services, filesystem permissions, or other hardening gaps. Many enterprise scanners bundle CVE and compliance checks in one credentialed task.

CVE, CWE, and CVSS for scan results

When a scanner cites a CVE, cross-check it before you report:

CVSS v4.0—the current specification—uses Base, Threat, Environmental, and Supplemental metric groups. Older CVSS v3.x references use the term Temporal metrics for time-varying factors such as exploit availability.

CVSS base score helps prioritize triage; it does not replace validation or business context. A critical CVE on an internal-only lab VM and the same CVE on an Internet-facing payment API do not carry equal risk. Penetration test remediation covers prioritization beyond CVSS alone.

Vulnerability scanning troubleshooting

Summary

Vulnerability scanning finds candidate weaknesses; assessment and penetration testing add triage, context, and proof. The main infrastructure axes are perspective (internal versus external), credentials (authenticated versus unauthenticated), and inspection method (network probe versus host/local or agent-based assessment). Scan timing controls intensity—it is not a separate magical scan mode.

Application work uses a different taxonomy: SAST on source, DAST on running apps, IAST on instrumented runtime paths, and SCA on third-party components. Compliance scans add baseline hardening checks beyond CVE matching.

The lab demos showed honest unauthenticated results: an Nmap SMB check that returned false, and Nikto lines that need manual validation. Separate scanner output from confirmed findings—especially on Linux, where backported patches can make version-based alerts misleading.

On a live engagement, map hosts with Nmap, run scoped vulnerability and web checks, validate the highest-signal items, and chain into exploitation or remediation only where the RoE allows.

References

• Nmap NSE documentation
• Nikto project
• MITRE CVE Program
• MITRE CWE
• FIRST CVSS v4.0 specification
• OWASP Web Security Testing Guide
• OWASP Software Component Verification Standard