Cybersecurity Home Lab Part 2: Vulnerability Scanning a Domain Controller with Nessus
Phase 1 of my home lab covered log ingestion and brute-force detection in Splunk. Phase 2 moves to the other side of the SOC coin: vulnerability management. I used Nessus Essentials to scan the same domain controller from Phase 1 — first without credentials, then with — to see firsthand how big a difference authenticated scanning actually makes.
What is Nessus, and Why Do Companies Use It?
Vulnerability management is the ongoing cycle organizations run to find weaknesses in their systems, figure out how much risk each one poses, and fix or mitigate them before an attacker gets there first. It’s not a one-time task — new vulnerabilities get disclosed constantly, so the cycle of scanning, assessing, and remediating never really stops.
Nessus is a vulnerability scanner built by Tenable. Point it at a host or network, and it checks for known security weaknesses — missing patches, misconfigurations, weak protocols, exposed services — then ranks each finding by severity and tells you how to fix it. It’s one of the most widely used tools in the industry for exactly that reason: it takes something that would be tedious and error-prone to check manually across dozens or hundreds of machines, and turns it into a scan you can run on a schedule.
Companies rely on tools like Nessus because attackers don’t need to find every weakness — they only need one. Regular vulnerability scanning is how a security team makes sure that one weakness doesn’t sit unnoticed for months (or, as this lab is about to show, years).
The Setup
My lab environment for this phase:
- AD-DC01, the same Windows Server 2022 domain controller (lab.local) from Phase 1, static IP 192.168.68.50
- Nessus-Scanner, a new dedicated Ubuntu Server VM running Nessus Essentials 10.12.3, static IP 192.168.68.51
I built the scanner as its own standalone VM rather than installing it alongside Splunk. Scan traffic is noisy, and I didn’t want it muddying SIEM data or competing for resources during a run — closer to how a real environment separates its tooling.
Prepping the Domain Controller
Before a credentialed scan can actually log in and inspect a host, the target needs a few things enabled. Since AD-DC01 runs Server Core, I did all of this through PowerShell instead of clicking through the Services and Registry Editor GUIs:
# Enable Remote Registry Set-Service -Name RemoteRegistry -StartupType Automatic Start-Service -Name RemoteRegistry
# Allow Network Discovery + File/Printer Sharing Set-NetFirewallRule -DisplayGroup “Network Discovery” -Enabled True Set-NetFirewallRule -DisplayGroup “File and Printer Sharing” -Enabled True
# UAC: never notify (testing only) Set-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System” ` -Name “ConsentPromptBehaviorAdmin” -Value 0
# Allow local account tokens for remote admin New-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system” ` -Name “LocalAccountTokenFilterPolicy” -Value 1 -PropertyType DWORD -Force
Worth flagging: every one of these settings weakens the host’s security posture. Fine for an isolated lab, never something you’d leave on in production.
Non-Credentialed Scan First
Get Shahmeermuhammad’s stories in your inbox
Join Medium for free to get updates from this writer.
I ran a Basic Network Scan against 192.168.68.50 with no credentials, just to see what an attacker would see poking the network from outside.
Nothing Critical, High, Medium, or even Low. The results were all reconnaissance-flavored — SMB details, DCE service enumeration, LDAP and Kerberos disclosure, OS fingerprinting. Useful information for an attacker doing recon, but nothing actionable on its own.
Credentialed Scan
Same target, same scan template, except this time I added domain admin credentials under the scan’s Credentials tab.
The difference was immediate and dramatic.
Credentials let Nessus actually log in and inspect what’s installed instead of guessing from the outside — and what it found was a domain controller with security patches missing since early 2022.
Two Standout Findings
KB5012604 — Windows Server 2022 Security Update (April 2022)
CVSS 9.8, EPSS 0.91 — meaning a 91% predicted likelihood of real-world exploitation — with exploit code maturity rated High. This single missing update bundles over 55 CVEs: privilege escalation, denial of service, remote code execution that bypasses authentication entirely, and information disclosure. The root cause traces back to ntoskrnl.exe, the Windows kernel binary itself, sitting unpatched for 730+ days.
KB5016627 — Windows Server 2022 Security Update (August 2022)
CVSS 9.8, EPSS 0.80. This one includes remote code execution and denial-of-service vulnerabilities in the Windows Point-to-Point Protocol implementation (CVE-2022–30133, CVE-2022–35744, among others) — again tracing back to the same unpatched kernel binary.
The remaining eight missing Critical and High severity KBs follow the same pattern — cumulative updates that, if applied, would likely resolve most of the backlog in one pass.
What I Learned
The gap between the two scans is the whole argument for credentialed vulnerability scanning, condensed into one comparison. Without credentials, Nessus can only report what’s visible from outside — banners, open ports, protocol handshakes. It found nothing actionable. With credentials, it could actually check installed patch levels against Microsoft’s bulletin history, and it surfaced 23 critical, actively-exploitable vulnerabilities that had been sitting there for over two years.
It’s a good reminder that a clean external scan doesn’t mean a clean host — it might just mean you’re not looking closely enough.
What’s Next
Phase 2 is complete: scanner built, domain controller prepped for authenticated scanning, and a clear before/after showing why credentials matter. Next up is Phase 3 — Microsoft Sentinel, built the same way as the first two phases: standalone first, integration later.
