Greenbone/OpenVAS Installation, Configuration & Vulnerability Assessment

📋 Overview

This project covers the complete deployment, troubleshooting, and execution of Greenbone Vulnerability Management (GVM/OpenVAS) within my SOC lab.

This was the second tool in Phase 3 of my SOC roadmap, directly following my Nmap reconnaissance project, where a --script=vuln NSE scan came back inconclusive. To move beyond lightweight, static checks, I deployed OpenVAS to run deep, actively-maintained vulnerability scanning.

This README documents the initial installation hurdles (specifically around feed synchronization), the successful execution of "Full and Fast" vulnerability scans against both a patched Windows 10 VM and a deliberately vulnerable Metasploitable 2 VM, and an analysis of the prioritized findings.

🖥️ Lab Setup

• Scanner: Kali Linux VM with Greenbone Vulnerability Manager (GVM) installed via apt
• GSA (Greenbone Security Assistant) Web UI: accessible locally at https://127.0.0.1:9392
• Target 1 (Hardened): Windows 10 VM (192.168.56.101), the primary host used throughout my Nmap, Suricata, Splunk, and ELK lab integrations
• Target 2 (Vulnerable Baseline): Metasploitable 2 VM (192.168.56.102), added specifically to provide a rich, target-dense environment for CVSS triage practice

⚙️ Installation & Initial Setup

sudo apt update
sudo apt install gvm -y
sudo gvm-setup

gvm-setup handles the full install: scanner, manager (gvmd), and web UI (GSA), while kicking off the initial feed synchronization for Network Vulnerability Tests (NVTs), CVEs, and CERT advisories. It also prints an auto-generated admin password for the GSA web UI.

Verified the install:

sudo gvm-check-setup

Started the services and logged into the GSA portal at https://127.0.0.1:9392 with the generated admin credentials.

🐛 Troubleshooting: Feed Synchronization

My first attempt to create a scan task against the Windows 10 target failed:

Failed to create a new Task because the default Scan Config is not available. This issue may be due to the feed not having completed its synchronization. Please try again shortly.

Rather than an installation failure, this turned out to be an asynchronous loading issue: gvm-setup exits before the substantial background feed sync actually completes. Without the Greenbone Data Objects Feed fully populated, default scan configs like "Full and Fast" simply don't exist yet.

I isolated the issue by confirming the core services were healthy before assuming anything was broken:

sudo runuser -u _gvm -- gvmd --get-scanners

08b69003-5fc2-4037-a479-93b440211c73  OpenVAS  /run/ospd/ospd-openvas.sock  0  OpenVAS Default
6acd0832-df90-11e4-b9d5-28d24461215b  CVE       0  CVE

Also confirmed GSA itself was listening correctly:

sudo ss -antp | grep 9392

Checking Administration → Feed Status in GSA confirmed the NVT feed had synced, but SCAP, CERT, and Data Objects feeds were all still actively downloading.

Manually confirmed/forced sync for each remaining feed type:

sudo runuser -u _gvm -- greenbone-feed-sync --type GVMD_DATA
sudo runuser -u _gvm -- greenbone-feed-sync --type SCAP
sudo runuser -u _gvm -- greenbone-feed-sync --type CERT

Monitored progress with:

watch -n 30 'sudo runuser -u _gvm -- gvmd --get-configs'

Once "Full and Fast" appeared in that output, the scanner was fully operational.

📊 Scan Execution & Vulnerability Results

With feeds fully synced, I configured and ran "Full and Fast" scans against both target hosts.

Scan Summary

Host IP	Host	High	Medium	Low	Total
192.168.56.101	Windows 10	0	1	2	3
192.168.56.102	Metasploitable 2	14	19	5	38

🪟 Windows 10 Target (192.168.56.101)

As expected for a modern, patched Windows host, the attack surface was minimal.

• Medium (CVSS 5.0): SSL/TLS Weak Cipher Suites Enabled. The host accepted 64-bit block ciphers (3DES/SWEET32).
  • Mitigation: disable 3DES cipher suites via GPO or registry.
• Low (CVSS 2.6): TCP Timestamps exposed, allowing system uptime approximation.
  • Mitigation: netsh int tcp set global timestamps=disabled

🐧 Metasploitable 2 Target (192.168.56.102)

The Linux target exposed severe, directly exploitable vulnerabilities across multiple legacy services, exactly as intended for this box.

• Critical (CVSS 10.0): vsftpd Backdoor Vulnerability (CVE-2011-2523). The FTP service contains a backdoor triggered by sending a sequence ending in :), opening a shell on port 6200.
  • Mitigation: upgrade vsftpd to a patched version or replace it with a secure FTP daemon.
• Critical (CVSS 10.0): UnrealIRCd Backdoor (CVE-2010-2075). The IRC daemon contains an unauthorized trojan backdoor allowing arbitrary command execution.
  • Mitigation: reinstall from a clean, verified source or upgrade to a modern IRC daemon.
• High (CVSS 7.5): Anonymous FTP + weak SSH credentials. Allowed read/write access to root directories via FTP and accepted default SSH keys.
  • Mitigation: disable anonymous write access, enforce strong password policy and public-key-only SSH authentication.

🗺️ MITRE ATT&CK Mapping

Finding	Technique	Tactic
vsftpd Backdoor	T1190 - Exploit Public-Facing Application	Initial Access / Execution
UnrealIRCd Backdoor	T1203 - Exploitation for Client Execution	Execution
Weak Credentials	T1110 - Brute Force	Credential Access

🧠 What I Learned

The clearest takeaway was learning to separate a successful package installation from actual operational readiness. Services can be fully running while their core dependencies, in this case vulnerability signature feeds, are still provisioning in the background. Rather than treating a generic GUI error as a structural failure, isolating each component (socket listeners, daemon status, feed sync state) let me correctly map out what was actually still in progress instead of assuming something was broken.

Running scans against two very different targets also taught me something about triage in practice. A 38-finding report on Metasploitable 2 isn't equally urgent line by line, remote code execution vectors like the vsftpd and UnrealIRCd backdoors need attention first, well before configuration weaknesses like TCP timestamp exposure. Prioritization by CVSS score alone gets you most of the way there, but exploitability and blast radius matter just as much as the raw number.

🎯 SOC Relevance

Vulnerability scanners are only as good as the recency of their signature databases. An out-of-date feed produces false negatives, which is exactly why monitoring feed currency is a real operational duty in a SOC, separate from just monitoring whether the scanner service itself is up. This lab walked through the practical vulnerability management flow end to end: discovery, assessment, triage, and remediation mapping. Comparing a hardened host against a deliberately vulnerable one also made the triage exercise concrete rather than theoretical, since a real analyst rarely gets a report as clean as the Windows 10 scan and needs practice working through a genuinely messy one like the Metasploitable 2 results.