Authenticated Nessus scans are good. For many reasons.
That said, when they fail, it can be difficult to figure out WHY they fail. This will be the second in a 3 part series of troubleshooting credentialed scans (Part 1). Today’s post is on Windows targets (and applies to Nessus 4.X – I will update for Nessus 5 soon, but 90% should be the same).
I’m not going to get into how to setup a credentialed scan for Windows here. That’s covered in the Nessus documentation and other places around the web. Also, many of the settings etc below are for troubleshooting/testing. In no way/shape or form is this considered a best practices for security guide. I am not responsible for the security configuration of your network/host/scanner. Practice defense in depth.
That said, some useful settings are below.
- General – Scan – Save Knowledge Base
This provides a detailed log of exactly what happened during the scan (though it can be a bit hard to read – not for the layman). The scan information is stored here:
- Windows Nessus Scanner: C:\Program Files\Tenable\Nessus\nessus\
- Unix based Nessus Scanner: /opt/nessus/var/nessus/users/
- General – Scan – Silent Dependencies
Personally, I don’t recommend that the average user should manually pick individual Nessus plugins to scan with unless you ‘really’ know what you’re doing. Just select everything (and select ‘Safe Checks’) and let Nessus sort it out. That said, if you hand pick your plugins, make sure to select this, otherwise you may not get complete data and many of the plugins I mention below may not trigger.
- Credentials – Windows Credentials
This is (surprise) where you setup the actual credentials to authenticate to the host with, but there are some important settings here too. Notable settings are below.
- SMB Domain (optional): If you are using an AD/LDAP or similar directory services account, be sure to set this. If you’re using a local account, leave it blank.
- SMB password type: Most folks will be using ‘Password’. If you’re using the LM or NTLM hash, you probably don’t need to read this article.
- Only use NTLMv2: While the security minded folks will probably want to check this, it can cause scans to fail when the target does not support NTLMv2. So if you’re absolutely sure that all of your hosts support it, you should enable it. If not, or if you’re troubleshooting something, make sure this is turned off.
- Preferences – Global variable settings – Do not log in with user accounts not specified in the policy
While this is a ‘good thing’ to leave off (if the target has default accounts, you’ll still get access and see all the data you need), it can be a pain when trying to reconcile valid accounts to valid targets. Enable this.
- Preferences – SMB Registry : Start the Registry Service during the scan
Un-needed services/programs should be disabled or uninstalled right? Security 101 (or 102). Some System Admins will disable the Remote Registry service (winreg) as well as the administrative shares (ADMIN$, IPC$, C$, etc) if they’re not needed. Unfortunately, they are needed to run a proper scan. That said, Nessus can enable and disable these features when it starts and finishes the scan. The two caveats are that the Remote Registry service can’t be ‘disabled’ (manual is fine), and the account you’re scanning with has to have rights to enable it (admin).
Useful Nessus Plugins to look for in the results:
- 10394: Microsoft Windows SMB Login Possible
- This tells you what account the scan used to login. Keep in mind, that the can ‘login’ with null sessions depending on your configuration, but not have access to anything else.
- 21745: Authentication Failure – Local Checks Not Run
- Either you fat-fingered your password somewhere, the account is locked out, or you don’t have rights to login.
- 24786: Nessus Windows Scan Not Performed with Admin Privileges
- Great! You logged in, but not with Admin rights. That’s a problem. Look at 10394 (above) to make sure your scanned logged in with the right account and then make sure your account has admin rights.
- 26917: Microsoft Windows SMB Registry : Nessus Cannot Access the Windows Registry
- This can trigger on a few occasions, but check to see if you have admin rights, and that the Remote Registry service is not disabled. If it’s set to Manual, then you need to start the service with the preference as mentioned above.
Things that are not Nessus
This is a handy little utility that Tenable put out. It can really help diagnose troublesome login issues. You can download/read about how to use it at the link above.
If you’re not familiar with nmap… get familiar with it. Like you’ll dog-sit for a nmap developer for a year kind of familiar. Use this to make sure that the proper ports are open… run it from the target, run it from the scanner, run it random places in-between. Nothing is more frustrating then troubleshooting a login issue for 3 months to realize that there was a rule set on a router that they ‘forgot’ about that blocked TCP 139/445 inbound. Sigh.
- Windows Event Viewer
Don’t forget about the Event Viewer of your target – especially the Security log. If this doesn’t show any events for failed or successful authentication, then you’re never actually reaching the host. Maybe-perhaps-fix-that.
- File/Print Sharing
This needs to be enabled on your target. This is how remote SMB authentication to Windows clients works. For production networks, this should probably be restricted for your scanners/specific accounts.
- The username and/or password is wrong in the scanner or wrong on the target.
- The account is locked out (local or ldap/AD)
- The account is AD, but no domain was supplied with the scan.
- File/Print Sharing is not enabled.
- The ‘insert name here’ host firewall is blocking the scan.
- The ‘insert name here’ host ‘Security Suite’ is blocking the scan.
- Proper services are not configured (winreg)
- The account is not actually on the target
- The host lost it’s trust relationship with the domain (you have bigger problems)
- The scanner is setup on Windows XP (or another Windows client OS). Go back and read Part 1. Fix. Come back.
- Local firewall that is blocking outbound connections
- Not powerful enough. (Have at least 2 GB of RAM – if the system can support 2GB RAM, other specs are in line.)
- Router/Firewall/Switch rules that block your traffic.
- Improperly tuned IPS devices.
- Overloaded network equipment (If your switch is more than 6 years old. Replace it. Revisit this page.)
- Network/Host admins that are not informed about what you’re doing and block/futz with your traffic.
- Gremlins/Demons. (I can’t help you with this one – I only know an old priest).