Expose
Check whether the service is reachable.
Project / Self-directed learning
Vulnerability
Validation Lab
From a scanner finding to evidence I can explain.
I built a deliberately vulnerable lab to practice service discovery, manual validation, and risk prioritization. This case study documents hands-on learning in my own lab.
01 / The setup
A controlled place
to ask better questions.
I used Kali Linux and a Metasploitable target in a VirtualBox host-only lab, with Nessus Essentials running on the host. My notes record an initial scan with 60+ findings, including 10 critical. Those are documented scan results, rather than a new measurement.
The goal was to understand which findings I could verify and what each result actually established.
02 / My approach
Expose. Confirm. Prove.
Confirm
Check whether it is the service or version the scanner reported.
Prove
Demonstrate the reported weakness where possible, and record what remains unknown.
03 / Evidence and limits
Three findings.
Three different conclusions.
VNC / Confirmed
Authentication weakness
I used Nmap to check exposure, Netcat to confirm the VNC response, and VNC Viewer to test authentication. My notes document a successful login using the known lab default and root-level remote access to the lab target.
This demonstrated the weakness in the deliberately vulnerable target. It does not establish compromise of another environment.
Read the VNC notesTomcat / Version confirmed
Unsupported software exposure
Nmap identified the web service, and the browser page displayed Apache Tomcat 5.5. This matched the scanner’s end-of-life finding.
I confirmed exposure and the displayed version. I did not demonstrate a Tomcat exploit.
Read the Tomcat notesSSL / Unconfirmed
An open question
Nessus reported SSL 2.0/3.0 support, but validation did not identify an exposed SSL/TLS service to confirm the finding.
The finding remains unconfirmed. Further investigation is needed; the notes do not establish a false positive.
Read the validation summary04 / Risk reasoning
Priority needs context.
In my scan analysis, I prioritized the reported unauthenticated bind shell over VNC despite the severity-score difference. The reasoning focused on authentication, direct command execution, and potential impact. This was a prioritization decision, not a documented manual validation of the bind shell.
I’m learning to ask about exposure, access, impact, and possible movement before deciding what deserves attention first.
05 / Transferable skills
Follow the evidence.
This work applies the same habits I use in technical troubleshooting: verify connectivity, identify the responding service, cross-check observations, and document the limits of the conclusion.
Tools: VirtualBox · Kali Linux · Metasploitable · Nessus Essentials · Nmap · Netcat · VNC Viewer
06 / Planned next steps
Validation is one part
of the lifecycle.
The public notes do not document implemented remediation or a successful post-fix retest. My next steps are to investigate the unresolved SSL finding, practice remediation in the lab, and retest to determine whether the changes address the findings.
Public project notes
Read the documented work.
The repository contains the scan summary, validation notes, and developing risk reasoning behind this case study.
View the public lab notes on GitHub