The Promise of Credentialed Scanning
An unauthenticated scan is like looking at a house from outside the fence. You can see the door, the windows, maybe a crack in the wall but you have no idea what's inside. A credentialed scan walks through the front door. It sees installed software, patch levels, registry configurations, and hundreds of vulnerabilities that are completely invisible from the outside.
That's why Tenable One recommends credentialed scanning as the baseline standard. And that's why when I deployed Tenable for an enterprise PoC engagement, credentials were the first thing I configured local admin accounts, SSH keys, everything before the first scan ever ran.
The results? Nearly empty.
The Environment
- Target: An enterprise internal network with a mix of Windows and Linux hosts.
- Security stack: Fortinet WAF sitting in front of most assets, configured with strict inspection policies.
- Scanner: Tenable Security Center, fully deployed, credentials loaded, scan policy set to credentialed mode.
The scan ran without obvious errors. But the coverage was suspiciously thin vulnerability counts were far below what you'd expect from a mature enterprise environment, and most credentialed check plugins simply didn't fire.
Root Cause: The WAF Was Silently Blocking Scan Traffic
Credentialed scanning on Windows requires access to specific protocols and ports:
| Protocol | Port | Purpose |
|---|---|---|
| SMB | 445 | Authentication and file access |
| WMI | Dynamic (RPC) | Software enumeration, services, registry |
| Remote Registry | — | Must be active on target host |
The problem: Fortinet WAF, by default, blocks or deeply inspects this traffic as an anomaly. From the WAF's perspective, an external host suddenly enumerating via SMB looks almost identical to lateral movement or active reconnaissance because it is, functionally, the same pattern.
The WAF didn't throw an error back to the scanner. The scan continued, but credentialed connections were silently dropped. Nessus detected the hosts, failed to authenticate, and silently fell back to unauthenticated mode no clear alert, no failed scan status. The report looked complete, but the data was hollow.
Scan Flow: Before (Blocked)
flowchart LR
A["Tenable SC\nNetwork Scanner"]
B["Fortinet WAF\nStrict Inspection Policy"]
C["Target Hosts\nWindows / Linux"]
D["Result\nCredentialed scan failed\nFallback to unauthenticated"]
A -- "SMB / WMI\nport 445, RPC" --> B
B -. "Blocked / Dropped\n(silent)" .-> C
B --> D
style B fill:#F5C4B3,stroke:#D85A30,color:#712B13
style D fill:#F7C1C1,stroke:#E24B4A,color:#791F1F
Key insight: The WAF doesn't have to actively reject the scan it just has to drop the packets silently. The scanner reports success; the coverage is worthless.
The Pivot: Nessus Agent
The solution: deploy Nessus Agent directly onto each target host.
The fundamental difference between network-based scanning and agent based scanning is the direction of traffic.
Scan Flow: After (Agent-Based)
flowchart LR
A["Tenable Manager\nAgent Controller"]
B["Fortinet WAF\n(not in path)"]
C["Target Host\nWindows / Linux"]
D["Nessus Agent\nRuns locally on host"]
E["Result\nFull credentialed coverage\nWAF has zero visibility"]
D -- "HTTPS outbound\nport 443 only" --> A
C -.->|bypassed| B
D --> E
style B fill:#D3D1C7,stroke:#888780,color:#5F5E5A
style D fill:#9FE1CB,stroke:#0F6E56,color:#085041
style E fill:#C0DD97,stroke:#3B6D11,color:#27500A
The agent operates entirely inside the host. It scans the local filesystem, registry, and installed packages without needing any inbound connection from outside. Results are shipped to Tenable Manager via outbound HTTPS traffic that WAFs almost universally permit because it looks identical to normal software update traffic.
Network Scan vs. Nessus Agent Side by Side
| Network Scan | Nessus Agent | |
|---|---|---|
| Traffic direction | Scanner → Target (inbound) | Agent → Manager (outbound) |
| Protocol | SMB, WMI, SSH | HTTPS port 443 |
| WAF visibility | Full all traffic passes through WAF | Zero outbound only |
| Credential storage | Scanner / scan policy | Agent itself (local) |
| Coverage reliability | Depends on network path | Always credentialed, always local |
| Deployment effort | Low (scan from one place) | Higher (agent on every host) |
| Best for | Asset discovery, unauthenticated checks | Deep VA in segmented / WAF protected envs |
Deployment Approach
Switching to agent-based scanning mid Proof-of-Concept requires a few steps:
1. Download and install Nessus Agent on target hosts
For Windows (via PowerShell or GPO):
msiexec /i NessusAgent.msi NESSUS_SERVER="tenable-manager.internal:8834" NESSUS_KEY="<linking-key>" /qn
For Linux (Debian/Ubuntu):
dpkg -i NessusAgent-<version>-debian6_amd64.deb
/opt/nessus_agent/sbin/nessuscli agent link \
--key=<linking-key> \
--host=tenable-manager.internal \
--port=8834
2. Verify agent registration in Tenable Manager
Check under Sensors → Nessus Agents agent should appear with status Active within a few minutes of linking.
3. Create an Agent Scan policy
In Tenable SC / Tenable.io: create a new scan using the Agent scan type, target the agent group, and run. No credentials needed in the scan policy the agent already has local access.
4. Validate credentialed coverage
Confirm that Nessus Plugin 21745 (authenticated check) fires in the results. If it's there, the scan was fully credentialed. If it's absent, something in the agent link or permissions is still broken.
Lessons Learned
1. Credentialed scan failure is not always obvious
The scanner will report the scan as "completed" even when all credentialed checks silently failed. Don't trust the status validate it. Check for Plugin 21745, look at the authenticated check count, compare vulnerability density against what you'd expect from a patched vs. unpatched system.
2. WAFs aren't just an attacker problem
A tightly configured WAF can block legitimate security tooling just as effectively as it blocks attackers. This needs to be surfaced before the PoC begins not as a WAF misconfiguration, but as a prerequisite discussion: do we add scanner IP exceptions, or do we switch to agents?
3. Agent deployment needs coordination
Agents need to be installed on every target host. In a large environment, this means coordinating with system owners, potentially involving multiple teams. Plan for distribution at scale: GPO for Windows, Ansible or Chef for Linux. Factor this into your PoC timeline.
4. Network scan and agent scan are complementary, not interchangeable
Network scanning is still valuable for asset discovery, external exposure assessment, and unauthenticated checks. Agent-based scanning is the right tool for deep vulnerability assessment in environments with WAFs or strict network segmentation. In most mature environments, you want both.
Closing
Vulnerability assessment is not just about running a scanner and exporting a report. It's about ensuring your scanner can actually see what it needs to see. In environments with WAFs, network segmentation, or strict inspection policies, that means understanding the communication paths your tooling requires and having an alternative when those paths are blocked.
Nessus Agent isn't a workaround. In many environments, it's the more reliable approach by design.
