On this page
Objective
This lab measures how authenticated access changes the depth and accuracy of a vulnerability scan.
Vulnerability management is a core responsibility in many security roles, and understanding the difference between what a scanner sees from the network and what it finds with valid credentials is fundamental. The lab answers one question: if an attacker has valid credentials to a Windows system, how many more vulnerabilities are exposed compared to an external scan?
The results
Total findings per scan
Same target, same Basic Network Scan template
| Severity | Unauthenticated | Credentialed | Change |
|---|---|---|---|
| Critical | 0 | 0 | — |
| High | 0 | 3 | +3 |
| Medium | 4 | 4 | — |
| Low | 1 | 2 | +1 |
| Info | 31 | 138 | +107 |
| Total findings | 36 | 147 | +111 |
The credentialed scan revealed roughly four times more findings. That’s expected, and it’s exactly why credentialed scanning is the standard in enterprise vulnerability management programs. The severity breakdown makes the point sharper: every High-severity issue on this host was invisible without credentials.
Lab environment
| Cloud platform | Microsoft Azure (LOG(N) Pacific Cyber Range) |
|---|---|
| Virtual machine | Windows 11 Pro, size Standard D2als v6 (2 vCPUs, 4 GiB RAM), private IP 10.2.0.25 |
| Scanner | Tenable Vulnerability Management, Basic Network Scan template |
| Scan engine | Internal scanner (LOCAL-SCAN-ENGINE-01) |
| Network access | Network Security Group (NSG) configured to allow Tenable scan traffic |
| Host firewall | Windows Firewall disabled for the lab so the scanner could communicate |
Windows Firewall was disabled only to eliminate firewall interference during scanning, which is appropriate only in an isolated lab. In production, you would use Tenable agent-based scanning or configure firewall rules specifically for the scanner.
Before the credentialed scan, I modified the LocalAccountTokenFilterPolicy registry value to enable remote administrative access for the Tenable scanner:
# Allow remote administrative access for Tenable
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
LocalAccountTokenFilterPolicy = 1 (DWORD)Scan 1: unauthenticated
The first scan ran with no Windows credentials. Tenable scanned the Azure VM from the network’s perspective only: it couldn’t log in to the operating system and was limited to what it could observe from outside.
| Scan type | Basic Network Scan |
|---|---|
| Credentials | None |
| Duration | ~9 minutes |
| Findings | 36 (0 Critical, 0 High, 4 Medium, 1 Low, 31 Info) |
| Visibility | External, network-level only |
Without credentials, Tenable could only identify what’s detectable from the network: open ports, service banners, externally observable SSL/TLS weaknesses, and network-exposed service issues. It had no visibility into the operating system’s patch state, installed software versions, registry settings, or local configuration.
The rated findings it did surface were all network-visible: an untrusted and self-signed SSL certificate, TLS 1.0 and TLS 1.1 still enabled (Medium), and ICMP timestamp disclosure (Low).
Scan 2: credentialed
The second scan used the same Tenable configuration with Windows local administrator credentials added, giving Tenable authenticated access so it could inspect the host from the inside.
| Scan type | Basic Network Scan |
|---|---|
| Credentials | Windows local administrator |
| Duration | ~23 minutes |
| Findings | 147 (0 Critical, 3 High, 4 Medium, 2 Low, 138 Info) |
| Visibility | Full host-level internal access |
With valid credentials, Tenable could read installed software, missing Windows patches, registry configuration, local security settings, service configurations, and application-level vulnerabilities. That’s the visibility a real vulnerability management program depends on.
The three High-severity findings
- The WinVerifyTrust signature validation mitigation for CVE-2013-3900 (EnableCertPaddingCheck) was not in place
- Security updates for Outlook for Windows (April 2024) were missing
- Microsoft Teams for Desktop was below the version that fixes a remote code execution vulnerability
Each depends on reading local configuration or installed software versions, which is why none of them appeared in the unauthenticated scan.
What the difference means
Missing OS patches, unpatched third-party software, insecure local configuration settings, and application-level vulnerabilities. All of these become visible only when the scanner can log in and inspect the host directly.
From an attacker’s perspective, the comparison shows what changes with valid credentials: an attacker with access gains visibility into the same additional attack surface the credentialed scanner reveals.
Screenshots
Key takeaways
- Unauthenticated scans are useful for identifying externally visible network exposure, but they represent only a fraction of actual host risk.
- Credentialed scans provide the accurate, complete picture that vulnerability management programs need for prioritization and remediation.
- CVSS scores help prioritize vulnerabilities, but only if the scanner can actually discover them, which requires credentials.
- NSG configuration and Windows Firewall rules directly affect scan results. Misconfigured access controls can silently reduce scan coverage.
- Cloud lab environments should be cleaned up after testing to avoid unnecessary cost and security exposure.
- The
LocalAccountTokenFilterPolicyregistry change is required to enable remote admin access for Tenable on modern Windows systems.