Windows

The Windows credentials menu item has settings to provide Nessus with information such as SMB account name, password, and domain name. By default, you can specify a username, password, and domain with which to log in to Windows hosts. Additionally, Nessus supports several different types of authentication methods for Windows-based systems: CyberArk, Kerberos, LM Hash, NTLM Hash, and Thycotic Secret Server.

Regarding the authentication methods:

  • The Lanman authentication method was prevalent on Windows NT and early Windows 2000 server deployments. It is retained for backward compatibility.
  • The NTLM authentication method, introduced with Windows NT, provided improved security over Lanman authentication. The enhanced version, NTLMv2, is cryptographically more secure than NTLM and is the default authentication method chosen by Nessus when attempting to log into a Windows server. NTLMv2 can make use of SMB Signing.
  • SMB signing is a cryptographic checksum applied to all SMB traffic to and from a Windows server. Many system administrators enable this feature on their servers to ensure that remote users are 100% authenticated and part of a domain. In addition, make sure you enforce a policy that mandates the use of strong passwords that cannot be easily broken via dictionary attacks from tools like John the Ripper and L0phtCrack. It is automatically used by Nessus if it is required by the remote Windows server. Note that there have been many different types of attacks against Windows security to illicit hashes from computers for re-use in attacking servers. SMB Signing adds a layer of security to prevent these man-in-the-middle attacks.
  • The SPNEGO (Simple and Protected Negotiate) protocol provides Single Sign On (SSO) capability from a Windows client to a variety of protected resources via the users’ Windows login credentials. Nessus supports use of SPNEGO Scans and Policies: Scans 54 of 151 with either NTLMSSP with LMv2 authentication or Kerberos and RC4 encryption. SPNEGO authentication happens through NTLM or Kerberos authentication; nothing needs to be configured in the Nessus policy.
  • If an extended security scheme (such as Kerberos or SPNEGO) is not supported or fails, Nessus will attempt to log in via NTLMSSP/LMv2 authentication. If that fails, Nessus will then attempt to log in using NTLM authentication.
  • Nessus also supports the use of Kerberos authentication in a Windows domain. To configure this, the IP address of the Kerberos Domain Controller (actually, the IP address of the Windows Active Directory Server) must be provided.

Server Message Block (SMB) is a file-sharing protocol that allows computers to share information across the network. Providing this information to Nessus will allow it to find local information from a remote Windows host. For example, using credentials enables Nessus to determine if important security patches have been applied. It is not necessary to modify other SMB parameters from default settings.

The SMB domain field is optional and Nessus will be able to log on with domain credentials without this field. The username, password, and optional domain refer to an account that the target machine is aware of. For example, given a username of joesmith and a password of my4x4mpl3, a Windows server first looks for this username in the local system’s list of users, and then determines if it is part of a domain.

Regardless of credentials used, Nessus always attempts to log into a Windows server with the following combinations:

  • Administrator without a password
  • A random username and password to test Guest accounts
  • No username or password to test null sessions

The actual domain name is only required if an account name is different on the domain from that on the computer. It is entirely possible to have an Administrator account on a Windows server and within the domain. In this case, to log onto the local server, the username of Administrator is used with the password of that account. To log onto the domain, the Administrator username would also be used, but with the domain password and the name of the domain.

When multiple SMB accounts are configured, Nessus will try to log in with the supplied credentials sequentially. Once Nessus is able to authenticate with a set of credentials, it will check subsequent credentials supplied, but only use them if administrative privileges are granted when previous accounts provided user access.

Some versions of Windows allow you to create a new account and designate it as an administrator. These accounts are not always suitable for performing credentialed scans. Tenable recommends that the original administrative account, named Administrator be used for credentialed scanning to ensure full access is permitted. On some versions of Windows, this account may be hidden. The real administrator account can be unhidden by running a DOS prompt with administrative privileges and typing the following command:

C:\> net user administrator /active:yes

If an SMB account is created with limited administrator privileges, Nessus can easily and securely scan multiple domains. Tenable recommends that network administrators consider creating specific domain accounts to facilitate testing. Nessus includes a variety of security checks for Windows Vista, Windows 7, Windows 8, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 that are more accurate if a domain account is provided. Nessus does attempt to try several checks in most cases if no account is provided.

Note: The Windows Remote Registry service allows remote computers with credentials to access the registry of the computer being audited. If the service is not running, reading keys and values from the registry will not be possible, even with full credentials. This service must be started for a Nessus credentialed scan to fully audit a system using credentials.

For more information, see the Tenable blog post.

Credentialed scans on Windows systems require that a full administrator level account be used. Several bulletins and software updates by Microsoft have made reading the registry to determine software patch level unreliable without administrator privileges, but not all of them. Nessus plugins will check that the provided credentials have full administrative access to ensure they execute properly. For example, full administrative access is required to perform direct reading of the file system. This allows Nessus to attach to a computer and perform direct file analysis to determine the true patch level of the systems being evaluated.

Option Default Description

Never send credentials in the clear

Enabled

For security reasons, Windows credentials are not sent in the clear by default.

Do not use NTLMv1 authentication

Enabled

If this option is disabled, then it is theoretically possible to trick Nessus into attempting to log into a Windows server with domain credentials via the NTLM version 1 protocol. This provides the remote attacker with the ability to use a hash obtained from Nessus. This hash can be potentially cracked to reveal a username or password. It may also be used to directly log into other servers. Force Nessus to use NTLMv2 by enabling the Only use NTLMv2 setting at scan time. This prevents a hostile Windows server from using NTLM and receiving a hash. Because NTLMv1 is an insecure protocol this option is enabled by default.

Start the Remote Registry service during the scan

Disabled

This option tells Nessus to start the Remote Registry service on computers being scanned if it is not running. This service must be running in order for Nessus to execute some Windows local check plugins.

Enable administrative shares during the scan

Disabled

This option will allow Nessus to access certain registry entries that can be read with administrator privileges.

CyberArk is a popular enterprise password vault that helps you manage privileged credentials. Nessus Manager can get credentials from CyberArk to use in a scan.

Option Description

Username

The target system’s username.

CyberArk AIM Service URL

The URL of the AIM service. By default, this field uses /AIMWebservice/v1.1/AIM.asmx.

Central Credential Provider Host

The CyberArk Central Credential Provider IP/DNS address.

Central Credential Provider Port

The port on which the CyberArk Central Credential Provider is listening.

Central Credential Provider Username

If the CyberArk Central Credential Provider is configured to use basic authentication, you can fill in this field for authentication.

Central Credential Provider Password

If the CyberArk Central Credential Provider is configured to use basic authentication, you can fill in this field for authentication.

Safe

The safe on the CyberArk Central Credential Provider server that contained the authentication information you would like to retrieve.
CyberArk Client Certificate The file that contains the PEM certificate used to communicate with the CyberArk host.
CyberArk Client Certificate Private Key The file that contains the PEM private key for the client certificate.
CyberArk Client Certificate Private Key Passphrase The passphrase for the private key, if required.
AppId The AppId that has been allocated permissions on the CyberArk Central Credential Provider to retrieve the target password.
Folder The folder on the CyberArk Central Credential Provider server that contains the authentication information you would like to retrieve.

PolicyId

The PolicyID assigned to the credentials you would like to retrieve from the CyberArk Central Credential Provider.

Use SSL

If CyberArk Central Credential Provider is configured to support SSL through IIS check for secure communication.

Verify SSL Certificate

If CyberArk Central Credential Provider is configured to support SSL through IIS and you want to validate the certificate check this. Refer to custom_CA.inc documentation for how to use self-signed certificates.

CyberArk Account Details Name

 The unique name of the credential you want to retrieve from CyberArk.
Option Default Description

Password

none

Like with other credentials methods, this is the user password on the target system. This is a required field.

Key Distribution Center (KDC)

none

This host supplies the session tickets for the user. This is a required field.

KDC Port

88

This option can be set to direct Nessus to connect to the KDC if it is running on a port other than 88.

KDC Transport

TCP

Note that if you need to change the KDC Transport value, you may also need to change the port as the KDC UDP uses either port 88 or 750 by default, depending on the implementation.

Domain

none

The Windows domain that the KDC administers. This is a required field.
Option Description

Username

The target system’s username.

Hash

Hash being utilized.

Domain

The Windows domain of the specified user’s name.
Option Description

Username

The target system’s username.

Hash

Hash being utilized.

Domain

The Windows domain of the specified user’s name.
Option Default Value

Username

(Required) The username for a user on the target system.

Domain

The domain of the username, if set on the Thycotic server.

Thycotic Secret Name

(Required) The Secret Name value on the Thycotic server.

Thycotic Secret Server URL

(Required) The value you want Nessus to use when setting the transfer method, target, and target directory for the scanner. Find the value on the Thycotic server, in Admin > Configuration > Application Settings > Secret Server URL.

For example, if you type https://pw.mydomain.com/SecretServer, Nessus determines it is an SSL connection, that pw.mydomain.com is the target address, and that /SecretServer is the root directory.

Thycotic Login Name

(Required) The username for a user on the Thycotic server.

Thycotic Password

(Required) The password associated with the Thycotic Login Name you provided.

Thycotic Organization

In cloud instances of Thycotic, the value that identifies which organization the Nessus query should target.

Thycotic Domain

The domain, if set for the Thycotic server.

Private Key

If enabled, Nessus uses key-based authentication for SSH connections instead of password authentication.

Verify SSL Certificate

If enabled, Nessus verifies the SSL Certificate on the Thycotic server.

For more information about using self-signed certificates, see Custom SSL Certificates.
Option Default Value

Username

(Required) The username to log in to the hosts you want to scan.
Domain The domain of the username, if required by BeyondTrust.

BeyondTrust host

(Required) The BeyondTrust IP address or DNS address.

BeyondTrust port

(Required) The port BeyondTrust is listening on.

BeyondTrust API key

(Required) The API key provided by BeyondTrust.

Checkout duration

(Required) The length of time, in minutes, that you want to keep credentials checked out in BeyondTrust. Configure the Checkout duration to exceed the typical duration of your Nessus scans. If a password from a previous scan is still checked out when a new scan begins, the new scan fails.

Note: Configure the password change interval in BeyondTrust so that password changes do not disrupt your Nessus scans. If BeyondTrust changes a password during a scan, the scan fails.

Use SSL

If enabled, Nessus uses SSL through IIS for secure communications. You must configure SSL through IIS in BeyondTrust before enabling this option.

Verify SSL certificate

If enabled, Nessus validates the SSL certificate. You must configure SSL through IIS in BeyondTrust before enabling this option.

Use private key

If enabled, Nessus uses private key-based authentication for SSH connections instead of password authentication. If it fails, the password will be requested.

Use privilege escalation

If enabled, BeyondTrust uses the configured privilege escalation command. If it returns something, it will use it for the scan.
Option Description Required
Username The target system’s username.

yes
Domain The domain, if the username is part of a domain.

no
Lieberman host

The Lieberman IP/DNS address.

Note: If your Lieberman installation is in a subdirectory, you must include the subdirectory path. For example, type IP address or hostname / subdirectory path.

yes
Lieberman port The port on which Lieberman listens.

yes
Lieberman API URL The URL Nessus uses to access Lieberman. no
Lieberman user The Lieberman explicit user for authenticating to the Lieberman RED API.

yes
Lieberman password The password for the Lieberman explicit user.

yes
Lieberman Authenticator

The alias used for the authenticator in Lieberman. The name should match the name used in Lieberman.

Note: If you use this option, append a domain to the Lieberman user option, i.e., domain\user.

no
Lieberman Client Certificate

The file that contains the PEM certificate used to communicate with the Lieberman host.

Note: If you use this option, you do not have to enter information in the Lieberman user, Lieberman password, and Lieberman Authenticator fields.

 no
Lieberman Client Certificate Private Key The file that contains the PEM private key for the client certificate. no
Lieberman Client Certificate Private Key Passphrase The passphrase for the private key, if required. no
Use SSL

If Lieberman is configured to support SSL through IIS, check for secure communication.

no
Verify SSL Certificate

If Lieberman is configured to support SSL through IIS and you want to validate the certificate, check this. Refer to custom_CA.inc documentation for how to use self-signed certificates.

no
System Name In the rare case your organization uses one default Lieberman entry for all managed systems, enter the default entry name.

no
Option Default Value

Arcon host

(Required) The Arcon IP address or DNS address.

Note: If your Arcon installation is in a subdirectory, you must include the subdirectory path. For example, type IP address or hostname/subdirectory path.

Arcon port

The port on which Arcon listens.
API User

(Required) The API user provided by Arcon.
API Key

(Required) The API key provided by Arcon.
Authentication URL The URL Nessus Manager uses to access Arcon.

Password Engine URL

The URL Nessus Manager uses to access the passwords in Arcon.
Username (Required) The username to log in to the hosts you want to scan.
Checkout Duration

(Required) The length of time, in hours, that you want to keep credentials checked out in Arcon.

Configure the Checkout Duration to exceed the typical duration of your Tenable.io scans. If a password from a previous scan is still checked out when a new scan begins, the new scan fails.

Note: Configure the password change interval in Arcon so that password changes do not disrupt your Tenable.io scans. If Arcon changes a password during a scan, the scan fails.
Use SSL If enabled, Nessus Manager uses SSL through IIS for secure communications. You must configure SSL through IIS in Arcon before enabling this option.
Verify SSL If enabled, Nessus Manager validates the SSL certificate. You must configure SSL through IIS in Arcon before enabling this option.
Option Default Value

Centrify Host

(Required) The Centrify IP address or DNS address.

Note: If your Centrify installation is in a subdirectory, you must include the subdirectory path. For example, type IP address or hostname/subdirectory path.

Centrify Port

 The port on which Centrify listens.
API User (Required) The API user provided by Centrify

API Key

 (Required) The API key provided by Centrify.
Tenant The name of a specified team in a multi-team environment.

Authentication URL

 The URL Nessus Manager uses to access Centrify.
Password Engine URL The name of a specified team in a multi-team environment.
Username (Required) The username to log in to the hosts you want to scan.
Checkout Duration

The length of time, in minutes, that you want to keep credentials checked out in Centrify.

Configure the Checkout Duration to exceed the typical duration of your Nessus Manager scans. If a password from a previous scan is still checked out when a new scan begins, the new scan fails.

Note: Configure the password change interval in Centrify so that password changes do not disrupt your Nessus Manager scans. If Centrify changes a password during a scan, the scan fails.
Use SSL If enabled, Nessus Manager uses SSL through IIS for secure communications. You must configure SSL through IIS in Centrify before enabling this option.
Verify SSL If enabled, Nessus Manager validates the SSL certificate. You must configure SSL through IIS in Centrify before enabling this option.