nessus-vulnerability-scanning-lab

Enterprise vulnerability management on Azure — Terraform-deployed Nessus scanner, credentialed scanning, CVE-2013-3900 remediation with verified re-scan

That jump in findings is the entire argument for credentialed scanning — the High-severity CVE-2013-3900 finding I remediated in this lab is a local check that the unauthenticated scan could not see at all.

Architecture

Dedicated NESSUS01 scanner appliance on Subnet-Servers with credentialed scan paths to all three Windows targets. Management plane reachable only via SSH tunnel from the admin workstation — port 8834 is never exposed publicly.

The scanner joins the existing lab VNet from my Enterprise Azure Infrastructure Automation series, deployed as an independent Terraform configuration with its own remote state.

Design decisions I made:

• Dedicated scanner VM instead of installing Nessus on a target. Enterprise scanners are placed as independent network appliances with unobstructed line-of-sight to their targets — scanning from a host that is also a target contaminates results.
• Terraform data sources against existing infrastructure. The scanner configuration references the existing VNet and subnet via data blocks rather than duplicating them, with state isolated in its own nessus-scanner.tfstate key so the scanner can be created and destroyed without touching the core lab state.
• Nessus web UI (port 8834) is never exposed publicly. The NSG allows only SSH (22) from my admin IP; I reach the UI through an SSH tunnel (ssh -L 8834:localhost:8834). Management-plane exposure is the number one way scanner appliances get compromised.
• SSH key authentication only — ed25519 key pair, no password auth on the scanner.

Phase 0 — Pre-Flight Security Review (Practice What You Scan)

Before deploying anything, I audited the existing NSG rules — and found exactly the kind of misconfiguration this lab exists to catch: the RDP rule allowed source * (any IP on the internet).

Pre-flight audit: az network nsg list query exposes Allow-RDP-3389 open to any source (*).

I tightened it to my current public IP before proceeding:

The same rule after remediation — source restricted to a single admin IP.

Finding and fixing an exposure in your own environment before pointing a scanner at it is the mindset shift from "running a tool" to "doing security."

Phase 1 — Deploy the Scanner with Terraform

Five resources — public IP, NSG, NIC, NSG association, and the Ubuntu VM — deployed in under two minutes:

terraform apply: 5 added, 0 changed, 0 destroyed. Outputs include the ready-to-use SSH command.

I then connected over SSH and performed the headless Nessus Essentials 10.12.1 install:

First SSH connection to NESSUS01 with key-based auth — Ubuntu 24.04 up at 10.0.1.8, ready for the headless Nessus install.

Phase 2 — Unauthenticated Baseline Scan

First scan: no credentials — this is what an attacker on the network segment sees.

Basic Network Scan targeting all three hosts: 10.0.1.5, 10.0.1.6, 10.0.1.7.

Baseline results: 35 findings across 3 hosts, Auth column showing Fail — Nessus could not log in, so every result comes from external observation only.

Phase 3 — Credentialed Scan

Credentialed scanning is the enterprise standard for internal vulnerability management. I prepared the Windows targets by enabling the Remote Registry service and opening the required firewall rule groups on the Domain profile:

Target preparation on FS01 — RemoteRegistry running with Automatic startup, WMI and File & Printer Sharing rules enabled for the Domain profile.

I configured Windows credentials in the scan with the security options enterprises require: never send credentials in the clear, and NTLMv2 only.

Windows credential configuration — domain LAB, NTLMv1 disabled, cleartext credential transmission disabled, Remote Registry auto-start enabled for the scan.

Credentialed results: 64 findings — an 83% increase over the unauthenticated baseline against the exact same three hosts.

Severity-sorted findings, with the High-severity WinVerifyTrust local check now visible — a finding the unauthenticated scan had no way to detect.

Phase 4 — Analyze the High Finding: CVE-2013-3900

Plugin #166555 flagged WinVerifyTrust Signature Validation (CVE-2013-3900) on both DC01 and FS01 — CVSS v3 base score 8.8, Tenable VPR 9.0. The EnableCertPaddingCheck registry value was missing, leaving the hosts in a state where an attacker could append malicious content to a signed executable without invalidating its Authenticode signature.

Full finding analysis: plugin output confirms the registry value is absent on 10.0.1.5 and 10.0.1.6, with the exact remediation path documented in the Solution section.

Why this finding matters: it is a mitigation-by-configuration vulnerability — no patch exists because Microsoft made the fix opt-in. It shipped missing on fresh Windows Server 2025 images in 2026, thirteen years after the CVE was published. This is exactly the class of issue only credentialed scanning and configuration management catch.

Phase 5 — Remediate and Verify

I applied the fix on the affected hosts per the plugin's Solution section — setting EnableCertPaddingCheck = 1 at both the 64-bit and Wow6432Node registry paths — then verified both keys before re-scanning:

Remediation applied and verified with Get-ItemProperty — both registry paths now return EnableCertPaddingCheck : 1.

Then the step most people skip — the verification re-scan. You don't close the ticket until the scanner confirms the finding is gone:

Verification scan (History: 2): the High-severity CVE-2013-3900 finding is resolved. Highest remaining severity is Medium.

Find → analyze → fix → verify. Loop closed.

Skills Demonstrated

Why This Matters for the Job

Vulnerability management is a core function in virtually every security operations, cloud security, and GRC role. This lab covers the whole job — not just running a scanner, but architecting its placement securely, preparing targets correctly, distinguishing signal from noise in the results, executing a remediation, and proving it worked. The unauthenticated-vs-credentialed comparison and the verification re-scan are the two things that separate practitioners from tool operators.

Assessment Report

The full professional deliverable — executive summary, methodology, detailed CVE-2013-3900 finding analysis, residual-risk disposition, and prioritized recommendations — is available as a PDF:

Vulnerability-Assessment-Report.pdf

Nessus Essentials does not include report export, so this deliverable was authored independently from the scan data — which is itself the assessment-reporting skill the free tier leaves out.

Related Labs

This scanner deploys into the environment built by my Enterprise Azure Infrastructure Automation series:

• Lab 1 — Terraform Infrastructure
• Lab 2 — Active Directory
• Lab 3 — NTFS File Server & RBAC
• Labs 4–6 — Azure RBAC

No secrets are stored in this repository — the scanner uses SSH key authentication only, and scan credentials were entered directly in the Nessus console, never committed to code.