A hands-on vulnerability management project demonstrating network discovery, authenticated Windows vulnerability assessment, risk analysis, remediation, and validation using Tenable Nessus.
This project simulates a real-world vulnerability management workflow against a Windows 11 endpoint in an isolated VirtualBox lab.
The assessment started with an unauthenticated network scan, which returned only informational findings. I then configured and validated authenticated Windows scanning to obtain deeper visibility into the host's local security configuration.
The authenticated assessment identified multiple security findings, including two High-severity issues.
One of the High-severity findings, CVE-2013-3900, was selected for remediation. The required Windows registry configuration was applied, verified after reboot, and then validated through a Nessus rescan.
The remediation was successful: CVE-2013-3900 was no longer detected after validation.
-
Perform an initial unauthenticated vulnerability assessment.
-
Configure authenticated Windows vulnerability scanning.
-
Troubleshoot and validate Nessus credentialed access.
-
Analyze vulnerability severity and risk.
-
Investigate a High-severity vulnerability.
-
Implement an appropriate remediation.
-
Verify the remediation locally.
-
Perform a post-remediation Nessus validation scan.
-
Document remaining security risk and remediation limitations.
| Category | Technology |
|---|---|
| Vulnerability Scanner | Tenable Nessus Essentials 10.12.5 |
| Target OS | Windows 11 Home |
| Scanner OS | Ubuntu 24.04.1 LTS |
| Virtualization | Oracle VirtualBox |
| Scripting / Administration | PowerShell |
| Network | VirtualBox Host-Only Adapter |
| Vulnerability | CVE-2013-3900 |
| Detection Method | Authenticated Nessus local checks |
VirtualBox Host-Only Network
192.168.56.0/24
│
┌────────────────┴────────────────┐
│ │
Nessus Scanner Windows Target
Ubuntu 24.04.1 Windows 11 Home
192.168.56.101 192.168.56.103
│ │
│ Authenticated │
└─────────── Assessment ──────────┘
The vulnerability assessment was performed entirely within an isolated lab network.
The assessment was performed in stages rather than immediately relying on an authenticated scan.
A Nessus Basic Network Scan was performed against:
192.168.56.103
The initial scan returned:
| Severity | Findings |
|---|---|
| Critical | 0 |
| High | 0 |
| Medium | 0 |
| Low | 0 |
| Informational | 3 |
The informational findings related to network/host information, including Ethernet manufacturer information, MAC addresses, and Nessus scan information.
This established a baseline but provided limited visibility into local Windows security configuration.
A second scan was configured using Windows credentials for the local administrative account.
The first credentialed attempt resulted in:
Auth: Fail
Rather than treating the scan as successful, I investigated the authentication problem.
The Windows host was configured to support the required authenticated assessment mechanisms, including:
-
SMB/File and Printer Sharing access
-
WMI access
-
Remote Registry
-
Local administrator remote-token configuration
After the configuration was corrected and the system rebooted, the authenticated scan was repeated.
The result:
Auth: Pass
This confirmed that Nessus was performing authenticated Windows checks.
The successful authenticated assessment identified:
| Severity | Findings |
|---|---|
| Critical | 0 |
| High | 2 |
| Medium | 1 |
| Low | 0 |
| Informational | 39 |
The two High-severity findings were:
CVE-2021-34527
Nessus Plugin: 151488
Severity: High
CVSS v3: 8.8
VPR: 9.5
The finding relates to an insecure Windows Print Spooler / Point and Print configuration.
Nessus reported that there was no available fix for the installed Windows version because the version was no longer supported.
This was therefore treated as an upgrade/platform remediation requirement, rather than applying an unsupported workaround solely to clear the Nessus finding.
CVE-2013-3900
Nessus Plugin: 166555
Severity: High
CVSS v3: 8.8
VPR: 9.5
Nessus identified missing EnableCertPaddingCheck registry values required to mitigate the vulnerability.
This finding was selected for the remediation exercise because Nessus provided a clear configuration-based remediation path that could be safely demonstrated within the lab.
Nessus reported that the following registry values were not present:
HKLM\Software\Microsoft\Cryptography\Wintrust\Config\
EnableCertPaddingCheck
HKLM\Software\Wow6432Node\Microsoft\Cryptography\Wintrust\Config\
EnableCertPaddingCheck
Because the Windows system was 64-bit, both registry locations were configured.
The required DWORD value was created and set to:
EnableCertPaddingCheck = 1
Both registry locations were then verified locally using PowerShell.
The Windows system was rebooted to ensure the configuration persisted.
After reboot, both registry locations continued to report:
EnableCertPaddingCheck : 1
This confirmed that the remediation was successfully applied before performing the validation scan.
A new Nessus scan was performed against the same Windows target using authenticated credentials.
The validation scan confirmed:
Auth: Pass
The previously detected CVE-2013-3900 / Nessus Plugin 166555 was no longer present in the vulnerability results.
BEFORE
CVE-2013-3900
High
CVSS 8.8
Plugin 166555
│
▼
REMEDIATION
EnableCertPaddingCheck = 1
│
▼
REBOOT + LOCAL VERIFICATION
│
▼
VALIDATION SCAN
Auth: Pass
│
▼
AFTER
CVE-2013-3900 no longer detected
This completed the vulnerability lifecycle:
Identify → Assess → Remediate → Validate
The PrintNightmare finding remains unresolved in the lab because Nessus reported that the installed Windows version is no longer supported and does not have an available vendor fix.
The appropriate remediation decision is therefore:
Upgrade or migrate the affected endpoint to a supported Windows version.
This demonstrates an important vulnerability-management principle: not every vulnerability can or should be resolved by changing a local configuration.
Where a vendor-supported remediation is unavailable, the correct response may involve upgrade, migration, compensating controls, or formally documented risk acceptance.
-
nessus-essentials-dashboard-ready.png -
nessus-scan-configuration.png -
nessus-baseline-hosts.png -
nessus-baseline-vulnerabilities.png
-
nessus-authenticated-credential-config.png -
nessus-authenticated-host.png -
nessus-authenticated-high.png -
nessus-authenticated-medium.png -
nessus-authenticated-informational.png
-
cve-2013-3900-before-remediation.png -
cve-2013-3900-remediation-applied.png -
cve-2013-3900-remediation-validated.png
-
nessus-validation-host.png -
nessus-validation-results.png
-
Vulnerability assessment
-
Authenticated Windows scanning
-
Nessus configuration
-
Vulnerability triage
-
CVE analysis
-
CVSS/VPR risk interpretation
-
Windows security configuration
-
PowerShell administration
-
Registry-based remediation
-
Vulnerability validation
-
Before/after assessment
-
Risk-based remediation decisions
-
Security documentation
This project reinforced that a vulnerability scan is only the beginning of vulnerability management.
The initial unauthenticated scan produced very limited results. Configuring authenticated access provided substantially deeper visibility into the Windows endpoint and revealed vulnerabilities that were not visible during the initial assessment.
I also learned the importance of validating scanner authentication rather than assuming a credentialed scan is working. The first authenticated attempt returned Auth: Fail, which required investigation before the results could be considered reliable.
Most importantly, the project demonstrated the full remediation lifecycle:
Detect → Investigate → Remediate → Validate
A successful remediation isn't simply making a configuration change—it is confirming through a subsequent assessment that the security finding has actually been resolved.
This project was performed in an isolated VirtualBox lab environment for educational and portfolio purposes.
No production systems were scanned or modified.