Using nmap scripts to enhance vulnerability asessment results

Published: 2013-07-01
Last Updated: 2013-07-01 23:48:03 UTC
by Manuel Humberto Santander Pelaez (Version: 1)
4 comment(s)

SCADA environments are a big interest for me. As responsible of the information security of an utility company, I need to ensure that risks inside those platforms are minimized in a way thay any control I place does not interfiere at all with the protocol and system function. That is why running things like metasploit or nexpose could be really dangerous if they are not well parameterized, as it could block the control to the RTU and IED and potentially cause a disaster if a system variable goes beyond control.

There is an alternative to perform vulnerability asessments to SCADA devices less risky and with good result information. You can use nmap scripting engine to add vulnerability scanning functionality. The software can be downloaded from The csv files are vulnerability databases and you need to place them into a directory named vulscan in the same directory as all other .nse scripts. The vulscan.nse script needs to be with all the other nse scripts. Once installed into the nmap scripts directory, you are all set.

Let's how it works. First step to perform vulnerability asessment is to check open ports and versions of all servers running there:


The vulscan script will get the service scan information as input to gather vulnerabilities inside the vulnerability databases. Now you need to use at least the following arguments:

  • Service scan: This nmap scan technique is able to query for open ports and determine which protocols and servers are running in those ports. Use -sV
  • Script selection: The script you want to use is vulscan.nse, so you should use --script=vulscan.nse.

You can also use any other optional arguments used normally with nmap, as well as arguments to the vulscan script, like:

  • SYN scan (-sS), connect scan (-sT) or operating system fingerprint (-O)
  • Script arguments: You can define which vulnerability database you want to use. The following databases are available: CVE (--script-args vulscandb=cve.csv), Security Tracker (--script-args vulscandb=securitytracker.csv), Security Focus (--script-args vulscandb=securityfocus.csv), Open Sourced Vulnerability Database (--script-args vulscandb=osvdb.csv) and Security Consulting Information Process Vulnerability Database (--script-args vulscandb=scipvuldb.csv). If you want to use all of them, don't use this argument to the script and leave only the script selection.

In the following example, nmap will perform a SYN scan, service scan and get the information as input to correlate with the Security Consulting Information Process Database. The command being run is  nmap -sS -sV --script=vulscan.nse --script-args vulscandb=scipvuldb.csv

nmap vulnerability script

In future diaries I will show other nmap scripts I like to perform vulnerability asessment and pentest.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
e-mail: msantand at isc dot sans dot org

4 comment(s)


Thanks for this info. SCADA environments are definitely sensitive and have to be treated with care. In one of my previous positions, I also worked with SCADA systems. In the utility industry (just like in any industry) there are many legacy SCADA systems that can't be upgraded without a major capital investment. I've seen a good number of NT 4.0 and even DOS (yes, Microsoft Disk Operating System) running SCADA at certain sites. An upgrade isn't simple and isn't cheap... many times an upgrade would involve upgrading many (1,000+) PLC controllers and literally replacing the entire communications infrastructure to run the latest version of the "vendor approved" SCADA system at the site. $1,000,000 to upgrade SCADA? Never happens and usually the entity will simply accept the risk and that's how and why we still have DOS systems running SCADA software that controls certain power plants.
It doesn't make sense to spend the millions on upgrades when these systems could simply be made NOT REMOTELY ACCESSIBLE.
You also have to be very careful with very old propriety systems like this that nmaping them won't take them down.

Do not attempt this when the plant is running.
> these systems could simply be made NOT REMOTELY ACCESSIBLE.

Then, make them NOT LOCALLY ACCESSIBLE, so that a compromised computer inside your network cannot "reach-out-and-touch" the SCADA system. (Alas, but this was the vector that already has been used.)

Diary Archives