Asset Detection with Nessus Scanners: The First Step In Assessing Cyber Risk

Building a precise inventory of existing assets across your attack surface is essential for effective vulnerability management. Here's how the asset detection process in Nessus scanners can help.

Compiling a complete asset inventory has always been a prerequisite for effective core vulnerability management (VM). With the attack surface continuously growing in size and complexity, it is more critical than ever that you identify all the assets in your network — not just your core IT assets but also any assets related to operational technology (OT) as well as any "shadow IT" assets. Any assets that are not properly managed pose additional risk.

Once you've identified all your assets, you need visibility into each of them in order to gather accurate information to assess your risk. Most vulnerability checks rely on publicly available information regarding the specific platforms and versions affected. Therefore, the accuracy of these checks depends on precise platform, software, version and patch information coming from the assets. 

While the Nessus scanner is well known for its ability to detect vulnerabilities, its capabilities to retrieve inventory information from the network may be slightly less known. However, the impact of these capabilities is substantial for:

1. increasing asset visibility and revealing blind spots;

2. core vulnerability management (VM), which heavily relies on the data points such as installed software and version; and 

3. risk-based VM (RBVM), precisely computing cyber exposure metrics for Lumin.


For Lumin metrics such as Asset Criticality Rating (ACR), the impact of asset inventory information is direct, as ACR is computed based on device type and capabilities. Other metrics, such as Asset Exposure Score (AES), rely on core VM information, and consequently on asset inventory information too.

Asset Detection in Nessus Scanners

Asset detection in Nessus scanners is performed by a number of Nessus plugins. While the vast majority of plugins (+95%) focus on vulnerability coverage, asset detection relies on accurate information about the host, which is retrieved via specialized plugins (most of them INFO severity). Note that Nessus scanners mainly focus on the IT space, including shadow IT assets, while OT assets are covered by other Tenable products, such as Tenable.ot.

The asset detection process is logically structured in four main phases, as shown in Figure 1: port scanning; service and protocol detection; software detection; and OS fingerprinting. These are logically sequential and performed by multiple plugins, which produce outputs that are consumed in subsequent phases. However, there may be some overlap between phases (some plugins for protocol detection may run at the same time as some plugins for software detection).

Figure 1: Nessus asset detection phases and outputs

The four phases of asset detection involve:

1. Port scanning: the Nessus scanner pings the host in different ways, retrieves the open ports and determines whether the scan should proceed.

2. Service and protocol detection: Nessus probes the open ports, looking for listening services and known protocols.

3. Software detection: the main goal is to list the different apps, their versions and patches available in the host.

4. Finally, with all the information coming from previous phases, Nessus tries to determine the OS and version of the remote host.


In the following sections, we describe the particular phases and the main families and plugins involved.

Port scanning 

A Nessus scan starts by checking if a given host is alive and, if that's the case, listing the ports that are found open. The Ping Remote Host plugin (10180) is usually the first plugin to run in a Nessus scan (although it can be disabled) when trying to determine if a given hostname or IP corresponds to a live target. If this plugin receives no response from the target, the host is marked as dead and the scan stops. Otherwise, Nessus will try to perform port scanning with a number of plugins from the port scanners family, which can be done remotely or locally (if credentials are available). Finding open ports is a critical step for any network scanner as it will enable subsequent service discovery and probing as well as further communication with the remote host.

Before continuing with the scan, Nessus checks if the host is likely to be a "fragile" asset, such as a printer or an OT device, which may be negatively affected by the large number and variety of requests that active scanning sends to a target. For this reason, a feature is enabled by default that protects fragile devices. "Stopper plugins," such as 22481 and 11933, will cancel the scan if a fragile device is detected.

Figure 2: Nessus port scanning phase

Service and protocol detection 

From the list of host open ports, the scanner performs service and protocol detection, mainly through plugins from the service detection family.

Service detection plugins (mainly plugin 22964) probe the open ports and analyze the response to determine which services are running on the remote host. Information regarding known and unknown services (e.g., service banner, service version or SSL encaps) is stored to be used by downstream plugins.

Subsequently, and based on the detected services, the scanner probes for specific protocols and their versions. These include HTTP (10582, 10107), SSL / TLS (21643), SSH (10267), Telnet (10280), SMB (10394, 10150), SNMP (40448) and SMTP (10263), among many others. Note that there are a couple of special cases here: part of the SMB and SSH probing takes place right after ping host, as these two protocols can be used for credentialed scans (and having these will enable local port scanning).

Figure 3: Nessus service detection phase

Software detection

Based on the information gathered about available protocols and services, the Nessus scanner will then try to detect specific apps, their versions, patches and additional information on the remote host. These detections can be classified into three main types: 

1. local detections, based on credentialed access and local system information; 

2. remote detections, probing and fingerprinting specific protocols and services; and

3. combined detections, which rely on both local and remote means to identify. 


It is worth noting that credentialed detections have a better chance of being successful and will provide more complete and reliable information than uncredentialed ones.

Local Detections

In the case of credentialed scans, the scanner runs a number of "local enumerators" for supported operating systems (Windows and Unix-based). The mission of these is to obtain information about general characteristics of the system, including installed patches and software (13855, 97993, 83991) as well as processes and services (110483, 70329). Subsequent plugins can pull this information for particular detections or other checks. We'll be able to see this better with a couple of specific examples, one for Windows and one for a Unix-based OS.

First, let's consider the case of a typical Windows local detection, for example for the Zoom client (118801). This plugin checks for Windows registry information coming from 13855. Depending on the information found there, additional checks will be performed against the registry and the filesystem, to retrieve version information and verify the location of the installation.

Figure 4: Local Zoom Windows detection plugin and dependencies run by Nessus scanners

Now let's consider the case of the local Java detection for Unix (64815). This is a slightly more complicated detection, given the number of different ways Java may be present on a system. In this plugin, a combination of checks are performed, based on filesystem information, package manager data and running processes.

Figure 5: Local Unix Java detection plugin and dependencies run by Nessus

Remote Detections

As mentioned, remote detections rely on probing and fingerprinting. Although not as precise as their local counterparts, remote detections do not require system credentials, and may help reveal blind spots in your network. As an example, we are going to explore remote HTTP-based detections.

HTTP-based detections are probably the most prevalent among remote Nessus detections, given how common web servers, web apps and HTTP communications are. Figure 6 shows an example of the HTTP-based detection of the Apache Web Server (plugin 48204). Here we can see the flow of information coming from the service and protocol detection (e.g., 10582), how additional plugins aggregate information for HTTP servers in general (e.g., 10107, 19689) and the Apache Web server in particular (see also 111465). 

Figure 6: Remote Apache HTTP server detection plugin and dependencies run by Nessus scanners.

Combined Detections

Finally, combined detections pull information from both local and remote sources. For example, Cisco IOS detection (47864) pulls information from remote SNMP plugins (10800, 10969), and also from local enumerators (12634). However, note that most of combined detections are not aggregated into a single plugin, but present separate local and remote detection plugins, such as Weblogic (71642, 71643, 73913) or Apache HTTP Server (48204, 141262, 141394), to name a couple. 

Figure 7: Nessus platform and software information phase

OS Identification 

OS identification is the last step in the asset inventory pipeline, as the scanner considers information gathered from all the previous phases to produce its best guess. As shown in Figure 8, the OS identification plugin (11936) relies on many other plugins and multiple protocols. Each of those plugins can produce their own guess, which has an associated confidence level. These confidence levels are defined on a case-by-base basis and depend heavily on the specific protocol and fingerprints involved.

In the following table, we can see a particular example with four fingerprinting methods. The OS identification plugin will choose the one with the highest confidence (SMB local), and report its guess as the identified OS. 

Source: Tenable

Note that only a subset of the fingerprinting methods may be able to produce an OS guess. For example, an HTTP guess (25247) will only be available if we detect HTTP on the remote host, are able to grab the banner and match a known OS fingerprint in the Nessus plugins. Also, note that different methods may be able to retrieve more detailed information than others: the probabilistic fingerprinter (132935) may be able to guess the base Linux distribution, while the Linux local fingerprinter (25335) can precisely identify the specific distribution, version and build.

Figure 8: Nessus OS identification phase

Fazit

Nessus asset inventory capabilities are a foundation stone for both traditional and risk-based vulnerability management. These capabilities are also useful on their own as a means for network inventory and to reveal blind spots. To this end, Tenable releases hundreds of asset detection plugins for new software and hardware yearly, so our customers are able to accurately determine their cyber exposure.

Mehr erfahren:

• Four Best Practices for Credentialed Scanning with Nessus

• How to Achieve 20/20 Visibility in Your OT Security

• Four Ways to Improve Nessus Scans Through Firewalls