To get all the vulnerability information with the Nmap Scripting Engine, perform the following steps:

1. There are a number of different ways in which one can identify the functions associated with any given NSE script. One of the most effective ways is to reference the script.db file that is located in the Nmap script directory. To see the contents of the file, we can use the cat command, as follows:

2. This script.db file is a very simple index that shows each NSE script's filename and the categories it falls into. These categories are standardized and make it easy to grep for specific types of script. The category name for vulnerability scanning scripts is vuln. To identify all vulnerability scripts, one would need to grep for the vuln term and then extract the filename for each script with the cut command. This can be seen in the following truncated output:

3. To further evaluate the use of any given script in the preceding list, one can use the cat command to read the .nse file that is contained within the same directory as the script.db file. Because most of the descriptive content is generally at the beginning of the file, it is recommended that you pipe the content over to the more utility so that the file can be read from top to bottom, as follows:

4. In the example provided, we can see that the smb-vuln-ms10-054.nse script checks for a remote memory corruption vulnerability associated with the SMB service. Here, one can find a description of the vulnerability and references to the Common Vulnerabilities and Exposures (CVE) number that can be queried online for additional information. By reading further, one can learn even more about the script, as follows:

5. By reading further down, we can find details on script-specific arguments, appropriate usages, and an example of the expected script output. It is important to take note of the fact that there is an unsafe argument that can be set to the value of 0 (not activated) or 1 (activated). This is actually a common argument in Nmap vulnerability scripts and it is important to understand its use.
6. By default, the unsafe argument is set to 0. When this value is set, Nmap does not perform any tests that could potentially result in a denial-of-service condition. While this sounds like the optimal choice, it often means that the results of many tests will be less accurate, and some tests will not be performed at all. Activating the unsafe argument is recommended for a more thorough and accurate scan, but this should only be performed against production systems in authorized testing windows. To run the vulnerability scan, the specific NSE script should be defined with the nmap --script argument, and all script-specific arguments should be passed using the nmap --script-args argument.
7. Also, to run the vulnerability scan with minimal distracting output, Nmap should be configured to only scan the port corresponding to the scanned service, as follows:

8. There is one more NSE script that I would like to draw attention to, because it teaches an important lesson about the practice of vulnerability scanning. This script is smb-vuln-ms10-061.nse. The details of this script can be seen by reading the script from the top down with the cat command piped over to more:

9. This vulnerability was one of four vulnerabilities that were exploited by the Stuxnet worm. The script checks for the vulnerability in a safe way without the possibility of crashing the remote system, as this is not a memory corruption vulnerability. In order for the check to work, it needs access to at least one shared printer on the remote system. By default, it tries to enumerate printers using the LANMAN API, which on some systems is not available by default. In that case, a user should specify the printer share name as a printer script argument. To find a printer share, smb-enum-shares can be used.
10. Also, on some systems, accessing shares requires valid credentials, which can be specified with the smb library arguments: smbuser and smbpassword. What makes this vulnerability interesting is the fact that there are multiple factors that must be true before it can actually be exploited:

11. In the example provided, the scanned system is not patched, but it also does not have a remote printer share. Have a look at the following example:

12. In the example provided, Nmap has determined that the system is not vulnerable because it does not have a remote printer share. While it is true that the vulnerability cannot be exploited, some would still claim that the vulnerability still exists because the system is unpatched and can be exploited in case an administrator decides to share a printer from that device. This is why the results of all vulnerability scanners must be evaluated to fully understand their results.
13. Some scanners will choose to evaluate only limited conditions, while others will be more thorough. It's hard to say what the best answer is here. Most penetration testers would probably prefer to be told that the system is not vulnerable because of environmental variables, so that they do not spend countless hours attempting to exploit a vulnerability that cannot be exploited.
14. Alternatively, a system administrator might prefer to know that the system is missing the MS10-061 patch so that the system can be totally secured, even if the vulnerability cannot be exploited under the existing conditions.