Automated vulnerability scanners are software tools that systematically identify and assess security weaknesses in computer systems, networks, and applications. These tools automate the process of scanning for known vulnerabilities, misconfigurations, and other security flaws, helping organizations proactively address potential threats before they can be exploited.
- Step 1. In the discovery phase, the scanner uses a tool such as Nmap to perform host and port enumeration. Using the results of the host and port enumeration, the scanner begins to probe open ports for more information.
- Step 2. When the scanner has enough information about the open port to determine what software and version are running on that port, it records that information in a database for further analysis. The scanner can use various methods to make this determination, including using banner information.
- Step 3. The scanner tries to determine if the software that is listening on the target system is susceptible to any known vulnerabilities. It does this by correlating a database of known vulnerabilities against the information recorded in the database about the target services.
- Step 4. The scanner produces a report on what it suspects could be vulnerable. Keep in mind that these results are often false positives and need to be validated. At the very least, this type of tool gives you an idea of where to look for vulnerabilities that might be exploitable.
Types of Vulnerability Scans#
The type of vulnerability scan to use is usually driven by scan policy that is created in the automated vulnerability scanning tool. Each tool has many options available for scanning. You can often just choose to do a full scan that will operate all scanning options, although you might not be able to use every option (for instance, if you are scanning a production environment or a device that is prone to crashing when scanning occurs). In such situations, you must be careful to select only the scan options that are less likely to cause issues. Let’s take a closer look at the following typical scan types:
- Unauthenticated Scans
- Authenticated Scans
- Discovery Scans
- Full Scans
- Stealth Scans
- Compliance Scans
Unauthenticated Scans#
By default, vulnerability scanners do not use credentials to scan a target. If you provide only the IP address of the target and click Scan, the tool will begin enumerating the host from the perspective of an unauthenticated remote attacker. An unauthenticated scan shows only the network services that are exposed to the network. The scanner attempts to enumerate the ports open on the target host. If the service is not listening on the network segment that the scanner is connected to, or if it is firewalled, the scanner will report the port as closed and move on. However, this does not mean that there is not a vulnerability. Sometimes it is possible to access ports that are not exposed to the network via SSH port forwarding and other tricks. It is still important to run a credentialed (or authenticated) scan when possible.
NOTE Authenticated scans may provide a lower rate of false positives than unauthenticated scans.
Authenticated Scans#
In some cases, it is best to run an authenticated scan against a target to get a full picture of the attack surface. An authenticated scan requires you to provide the scanner with a set of credentials that have root-level access to the system. The scanner actually logs in to the target via SSH or some other mechanism. It then runs commands like netstat to gather information from inside the host. Many of the commands that the scanner runs require root-level access to be able to gather the correct information from the system.
Discovery Scans#
A discovery scan is primarily meant to identify the attack surface of a target. A port scan is a major part of what a discovery scan performs. A scanner may actually use a tool like Nmap to perform the port scan process. It then pulls the results of the port scan into its database to use that information for further discovery. For instance, the result of the port scan might come back showing that ports 80, 22, and 443 are open and listening. From there, the scanning tool probes those ports to identify exactly what service is running on each port. For example, say that it identifies that an Apache Tomcat 8.5.22 web server is running on ports 80 and 443. Knowing that a web server is running on the ports, the scanner can then perform further discovery tasks that are specific to web servers and applications. Now say that, at the same time, the scanner identifies that OpenSSH is listening on port 22. From there, the scanner can probe the SSH service to identify information about its configuration and capabilities, such as preferred and supported cryptographic algorithms. This type of information is useful for identifying vulnerabilities in later phases of testing.
Full Scans#
As mentioned previously, a full scan typically involves enabling every scanning option in the scan policy. The options vary based on the scanner, but most vulnerability scanners have their categories of options defined similarly. For instance, they are typically organized by operating system, device manufacturer, device type, protocol, compliance, and type of attack, and the rest of the options might fall into a miscellaneous category. Example 3-44 shows a sample list of the plugin categories from the Nessus vulnerability scanner. As you can see from this list, there are a lot of plugins available for the scanner to run. It should also be obvious, based on the names of the plugin categories, that there will never be a single device that all of these plugins apply to. For instance, plugins for a macOS device would not be applicable to a Windows device. That is why you normally need to customize your plugin selection to reflect the environment that you are scanning. Doing so will reduce unnecessary traffic and speed up your scanning process.
Stealth Scans#
There are sometimes situations in which you must scan an environment that is in a production state. In such situations, there is typically a requirement for running a scan without alerting the defensive position of the environment; such a scan is called a stealth scan. In this case, you will want to implement a vulnerability scanner in a manner that makes the target less likely to detect the activity. Vulnerability scanners are pretty noisy; however, there are some options you can configure to make a scan quieter. For example, as discussed earlier in this module, there are different types of Nmap scans, and they can be detected by network intrusion prevention systems (IPSs) or host firewalls. You have learned that a SYN scan is a fairly stealthy type of scan to run. This same concept applies to vulnerability scanners because they all use some kind of port scanner to enumerate the target. These same options are available in the vulnerability scanner’s configuration. You can also disable any plugins/attacks that might be especially likely to generate noisy traffic, such as any that perform denial-of-service attacks, which would definitely arouse some concerns on the target network.
Passive Vulnerability Scanner#
Aside from the modifications to a traditional vulnerability scanner just described, there is also the concept of a passive vulnerability scanner. A passive vulnerability scanner monitors and analyzes the network traffic. Based on the traffic it sees, it can determine what the topology of the network consists of and what service the hosts on the network are listening on. From the detailed information about the traffic at the packet layer, a passive vulnerability scanner can determine if any of those services or even clients have vulnerabilities. For instance, if a Windows client with an outdated version of Internet Explorer is connecting to an Apache web server that is also outdated, the scanner will identify the versions of the client and server from the monitored traffic. It can then compare those versions to its database of known vulnerabilities and report the findings based on only the passive monitoring it performed.
Compliance Scans#
Compliance scans are network and application tests (scans) typically driven by the market or governance that the environment serves and regulatory compliance. An example of this would be the information security environment for a healthcare entity, which must adhere to the requirements sent forth by the Health Insurance Portability and Accountability Act (HIPAA). This is where a vulnerability scanner comes into play. It is possible to use a vulnerability scanner to address the specific requirements that a policy requires. Vulnerability scanners often have the capability to import a compliance policy file. This policy file can typically map to specific plugins/attacks that the scanner is able to perform. Once the policy is imported, the specific set of compliance checks can be run against a target system.
The challenge with compliance requirements is that there are many different types for different industries and government agencies, and they can all be interpreted in various ways. Some of the checks might be straightforward. If a requirement check is looking for a specific command to be run and that the output be a 1 instead of a 0, that is very simple for a vulnerability scanner to determine; however, many requirements leave more to be interpreted. This makes it very difficult for a tool like a vulnerability scanner to make a determination. Most vulnerability scanners also have the capability to create custom compliance policies. This is a valuable option for penetration testers, who typically want to fine-tune the scanner policy for each engagement.
Example#
- nmap vulners script scan#
- Nessus#
- Greenbone Vulnerability Management (GVM)#
Ref: