Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Using nmap scripts to enhance vulnerability asessment results - SANS Internet Storm Center SANS ISC InfoSec Forums

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Using nmap scripts to enhance vulnerability asessment results

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

Manuel Humberto Santander Pelaacuteez

185 Posts
ISC Handler
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.

69 Posts
It doesn't make sense to spend the millions on upgrades when these systems could simply be made NOT REMOTELY ACCESSIBLE.

3 Posts
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.

19 Posts
> 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.)

Sign Up for Free or Log In to start participating in the conversation!