Vulnerability Management Lab

The goal of this lab was to work through the complete vulnerability management lifecycle — discover, assess, prioritize, remediate, and verify — using the same scanning engine (Nessus) that enterprise security teams rely on. Specifically I aimed to:

• Build an isolated lab environment with a scanner and a deliberately vulnerable target
• Run both uncredentialed (external attacker view) and credentialed (authenticated) scans
• Establish a baseline and identify the most severe findings
• Remediate exploitable services and re-scan to measure the impact
• Make and document risk-based decisions on vulnerabilities that could not be cleanly fixed

The lab ran entirely on a single Windows 11 host using VirtualBox. The scan target was Metasploitable 2, a purpose-built vulnerable Linux VM. Critically, the target was placed on a Host-Only network, fully isolated from the internet — vulnerable systems should never be exposed to a live network.

Nessus Essentials was installed on the Windows host, running as a local web application at https://localhost:8834. After registering for a free activation code and letting the plugin feed fully update, the scanner was ready to assess the target.

I followed the vulnerability management lifecycle end to end — baselining the target from two perspectives before making any changes, then iterating on remediation and verification.

The baseline credentialed scan revealed a heavily vulnerable system, as expected from Metasploitable. Comparing the uncredentialed and credentialed scans is itself instructive — an authenticated scan typically surfaces more findings because it can inspect the system from the inside.

The credentialed scan surfaced more informational and mixed findings (Info jumped from 46 to 60), confirming the deeper visibility authenticated access provides. Notably, the Critical count barely changed between the two — a reflection of just how openly exploitable Metasploitable is: most of the worst issues are visible even without credentials. The credentialed baseline (6 Critical / 3 High) was used as the reference point for remediation.

Remediation was carried out over two rounds. Rather than blindly killing services, I used netstat -tulnp to map listening ports back to their services, then targeted the ones tied to the most severe findings. I worked over SSH from the Windows host — the same way a real admin would manage a remote box — which also made commands and output easy to capture.

After each action I verified the service was actually down with ps aux | grep <service> before moving on. Across both rounds, nine exploitable services were disabled.

Important caveat (and a real-world lesson): these were runtime stops — the services are down now, but would return on reboot. In production, a permanent fix means disabling them at startup or removing the packages entirely. Because the rescan was run without rebooting, the results accurately reflect the remediation.

The two exposed databases (MySQL on 3306 and PostgreSQL on 5432) were deliberately left running. Unlike the backdoored services, databases aren't inherently critical — they flag for weak credentials or network exposure. The correct real-world remediation is credential hardening and network ACLs, not shutting the database off. They are documented below as a remediation plan rather than a kill.

Re-running the credentialed scan against the hardened target confirmed a measurable reduction across every severity category.

An important nuance: nine services were disabled but Critical findings dropped by two, not nine. That's because severity counts don't map one-to-one with services — some services trip High/Medium findings rather than Critical, and the remaining Criticals live in the operating system and core libraries, not in optional services. Recognizing that a vulnerability count isn't the same as the number of distinct problems is part of accurate triage.

Real vulnerability management is about triage, not chasing zero. The four remaining Critical findings actually trace back to three distinct root causes — Nessus reported the Debian key weakness twice because it detected it through two separate methods (SSL and SSH). Each remaining issue was given a documented disposition.

Bash Remote Code Execution (Shellshock)

Critical

The target runs a version of Bash vulnerable to command injection via environment variable manipulation, allowing remote arbitrary code execution. Nessus's prescribed fix is simply "Update Bash" — a patch-level remediation, not a service that can be disabled.

CVE:CVE-2014-6271

Fix Type:Package patch (Bash)

Disposition:Accepted risk — patching not feasible on EOL OS; in production, update Bash or apply compensating controls (segmentation, monitoring)

Debian OpenSSH/OpenSSL Weak Keys

Critical

A 2008 Debian packaging bug crippled the random number generator, so SSH/SSL keys were drawn from a tiny, brute-forceable pool. Nessus flagged this twice — once via SSL detection, once via SSH — but both stem from the same root cause. This one is remediable at the config level by removing the predictable keys from authorized_keys.

CVE:CVE-2008-0166

Detected By:2 plugins (SSL + SSH) — single root cause

Fix Type:Config — regenerate keys, remove predictable ones

Disposition:Documented remediation plan — risk mitigated in lab by host-only network isolation

SSLv2 / SSLv3 Protocol Detection (POODLE)

Critical

The target supports obsolete SSLv2 and SSLv3 protocols. SSLv3 is vulnerable to the POODLE attack and both are long broken. The fix is to disable these protocols in the affected service's configuration and restart it.

CVE:CVE-2014-3566 (POODLE)

Fix Type:Config — disable SSLv2/v3 (e.g. SSLProtocol -all +TLSv1.2)

Disposition:Documented remediation plan — not executed due to legacy software stack