Brick #6 - Vulnerability Management Lab (VulnHub)

A hands-on vulnerability management lab performed against multiple VulnHub targets in an isolated VirtualBox host-only network. This Brick captures the full lifecycle: discover → scan → triage → validate → remediation plan → verify.

---

Objective

Demonstrate a repeatable, employer-aligned vulnerability management workflow using real evidence artifacts:

• Asset discovery and inventory
• Service/version enumeration (Nmap)
• Risk-based triage (P1/P2/P3)
• Validation of at least one high-impact finding per asset
• Remediation planning and compensating controls
• Verification scans and summarized reporting

---

Lab Safety

• All targets were hosted on a VirtualBox Host-only network (vboxnet0) to prevent exposure to the home/public network.
• Scanning and validation were performed from a Kali host within the isolated segment.
• No scanning was performed against real systems or external networks.

---

Environment

• Host OS: Kali Linux (Live USB with persistence)
• Hypervisor: VirtualBox
• Lab Network: vboxnet0 (host-only) / 192.168.56.0/24
• Targets: VulnHub OVAs (see asset inventory)

---

In-Scope Targets (Enterprise Segment)

This Brick uses three targets to simulate a small “enterprise segment” with different roles and attack surfaces:

• EMP (Legacy) – exposed admin/shell endpoint and risky HTTP method behavior
• ColddBox (Web) – outdated WordPress stack with common WP endpoints exposed
• Hackable II (App) – legacy services including anonymous FTP exposure

See asset-inventory/assets.md for IP/MAC and observed services.

---

Workflow Summary

1) Discovery and Asset Inventory

• Identified live hosts on vboxnet0 using ARP-based discovery.
• Recorded assets, roles, and observed exposure.

Artifacts:

• scans/nmap_ping_arp.txt
• scans/arp_scan_*
• asset-inventory/assets.md

2) Baseline Enumeration (Nmap)

• Captured baseline service and version exposure for each asset.

Artifacts:

• scans/nmap_initial_*.txt

3) Validation (Proof of Risk)

Validated at least one meaningful finding per asset using non-invasive checks:

• EMP (Legacy): robots.txt disclosure + reachable /phpbash.php + TRACE enabled
• ColddBox (Web): WordPress 4.1.31 confirmed + xmlrpc.php and wp-login.php reachable + exploit references collected
• Hackable II (App): anonymous FTP allowed + file CALL.html listed and downloaded

Artifacts (examples):

• EMP: scans/robots_EMP_legacy.txt, scans/phpbash_head_EMP_legacy.txt, scans/http_trace_EMP_legacy.txt
• ColddBox: scans/wp_fingerprint_*.txt, scans/searchsploit_wordpress_4.1.31.txt, scans/xmlrpc_head_*.txt, scans/wp_login_head_*.txt
• Hackable II: scans/ftp_anon_session_HackableII.txt, scans/ftp_CALL_html_fileproof.txt, CALL.html

4) Triage (Risk-Based Prioritization)

Findings were prioritized using:

• exposure level
• exploitability (unauthenticated vs authenticated)
• business impact (data exposure / potential code execution)

Artifacts:

• triage/triage.md
• triage/summary.md

5) Remediation Planning + Compensating Controls

Because VulnHub targets are intentionally vulnerable and not always realistically patchable, remediation includes:

• preferred fixes (patch/upgrade/remove service)
• compensating controls (WAF rules, IP allowlists, segmentation, port restrictions)

Artifacts:

• remediation/changes.md

6) Verification

Targeted verification scans were captured to establish a repeatable “verify” step and provide before/after baselines.

Artifacts:

• scans/nmap_verify_*.txt

---

Key Findings (High Level)

• P1: Exposed admin/shell endpoint disclosed via robots.txt (/phpbash.php) on EMP (Legacy)
• P1: Outdated WordPress Core (4.1.31) exposed on ColddBox (Web)
• P1: Anonymous FTP enabled (ProFTPD) allowing unauthenticated file access on Hackable II (App)
• P2: HTTP TRACE enabled on EMP (Legacy)
• P2: xmlrpc.php and wp-login.php reachable on ColddBox (Web)

See triage/summary.md for the condensed risk register and remediation order.

---

Evidence Map (Where to Look)

• Asset inventory: asset-inventory/assets.md
• Baseline scans: scans/nmap_initial_*.txt
• Validation proof:
  • EMP: scans/robots_EMP_legacy.txt, scans/phpbash_head_EMP_legacy.txt, scans/http_trace_EMP_legacy.txt
  • ColddBox: scans/wp_fingerprint_*.txt, scans/searchsploit_wordpress_4.1.31.txt, scans/xmlrpc_head_*.txt, scans/wp_login_head_*.txt
  • Hackable II: scans/ftp_anon_session_HackableII.txt, scans/ftp_CALL_html_fileproof.txt, CALL.html
• Triage: triage/triage.md, triage/summary.md
• Remediation plan: remediation/changes.md
• Verification: scans/nmap_verify_*.txt
• Screenshots: screenshots/
• Final project tree: logs/final_tree.txt

---

Skills Demonstrated

• Vulnerability management lifecycle execution
• Asset discovery and inventory management
• Service and version enumeration (Nmap)
• Web exposure validation (curl, HTTP method checks)
• Risk-based triage and prioritization (P1/P2/P3)
• Remediation planning + compensating controls
• Evidence-driven documentation and reporting

---

Notes

• IP addresses may change due to host-only DHCP; service fingerprints and artifacts were used to confirm asset identity.
• This Brick is designed as a repeatable template for future vulnerability management assessments.

---

Related projects

This lab is part of a portable Kali Live USB security platform:

• live-usb-encrypted-persistence — Brick #1 (host platform)
• cyberdeck-platform — Brick #2 (hardware)
• interface-hud-operator-controls — Brick #3 (HUD)
• toolchain-layer — Brick #4 (security tools used here)
• logging-siem-wazuh — Brick #5 (SIEM that ingests these scans)
• vulnerability-management-lab (this repo) — Brick #6
• azure-security-monitoring-lab — cloud counterpart in Azure

---

Author

Charles Tucker — github.com/RealPhantomLee