Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Tenable Blog

  • Twitter
  • Facebook
  • LinkedIn

Using the 'nasl' Nessus Command Line Tool

This blog entry will discuss the usage of the Nessus nasl binary tool. It will also discuss which plugins work well with the tool, how credentials and other information can be supplied at scan time and how the tool can make use of data saved in a prior scan's knowledge base.

As of Nessus v6 the command line utilities for running Nessus scans are no longer included. Customers are encouraged to use the Nessus API to implement command line base scanning, and a host of other features include uploading and downloading reports. Customers can find examples in the Tenable Discussion Forum, and in particular the post "Nessus v6 API Demo Scripts" and documentation.

The nasl Binary

The nasl tool allows NASL scripts to be invoked, traced and analyzed. This can help in debugging new NASL scripts and analyzing the logic of various plugins. On Linux distributions of Nessus, the nasl binary is located in /opt/nessus/bin/nasl. This is the directory that also contains the nessus client and nessus-fetch tools. Running it without any arguments will offer the usage page and running it with the '-v' option will show you the version information.

Configuring Your System to run the nasl Binary

The nasl binary is installed with each version of Nessus 3. You can run the nasl binary as any user that has access to execute the binary. Some options, such as forging packets, require root access. The nasl binary is also installed with Nessus 2, but does not support execution of .nbin files or dynamic reading from the knowledge base. Also, the nasl binary does not support plugins with the .nes extension. These plugins are written in the C language and implement platform specific logic.

If you will be running the nasl command a lot, you should consider placing /opt/nessus/bin into your executable environment path. This allows you to do work in the /opt/nessus/lib/nessus/plugins directory and not re-type the full path to the nasl binary.

The nasl binary works with  plugins from the Registered and Direct Feeds. If your Nessus 3 scanner is subscribed to the Direct Feed, it will be able to perform configuration, sensitive content and SCADA scans. Instead of invoking the nasl binary with a plugin that has a .nasl extension, some Direct Feed plugins are shipped with .nbin extensions which signifies that their code has been shipped in binary format.

Which Plugins work best?

Of the more than 15,000 Nessus plugins available in the Direct or Registered feeds each can be classified into two types: those dependent on other plugins for input and those that can run stand-alone. The nasl binary can run any NASL script, but if the script expects to work with data produced by another plugin, the specific knowledge base (KB) must be referenced. We will discuss the KB in a moment, but first let's look at some example plugins being invoked by the nasl binary which don't depend on the KB.

All plugins that require credentials such as performing file content checks or reading the registry will be dependent on other plugins for input.   

Example Network Banner Check

We will start off by connecting to port 80 on an older Fedora Apache server:

[[email protected] plugins]# telnet 80
GET / HTTP/1.0

Connected to (
Escape character is '^]'.
HTTP/1.1 200 OK
Date: Sun, 24 Jun 2007 13:16:35 GMT
Server: Apache/2.0.47 (Fedora)

This system is running Apache 2.0.47. Now let's run two of the Apache NASL checks against this host:

[[email protected] plugins]# /opt/nessus/bin/nasl -t ./apache_2_0_47.nasl
[[email protected] plugins]# /opt/nessus/bin/nasl -t ./apache_2_0_48.nasl
./apache_2_0_48.nasl: Success

We can see that the apache_2_0_47.nasl script didn't find anything while the apache_2_0_48.nasl did. These checks are a good example of a network check that doesn't require authentication information or access to the KB. Both checks basically connect to the web server, obtain the banner and look for a certain version number.

Some of the more than 15,000 Nessus plugins are very useful is a pure "stand-alone" type of audit. A good example of this is the  ssl_supported_ciphers.nasl plugin which reports a wide variety of information about the encryption available on remote systems. Below is an example run which has had it's output curtailed for this blog entry:

[[email protected] plugins]# /opt/nessus/bin/nasl -t ./ssl_supported_ciphers.nasl

Synopsis :

The remote service supports the use of weak SSL ciphers.

(Description and solution removed)

Plugin output :
Here is a list of the SSL ciphers supported by the remote server :

(Low Strength and medium Strength Ciphers removed)

  High Strength Ciphers (>= 112-bit key)
      DES-CBC3-MD5               Kx=RSA        Au=RSA     Enc=3DES(168)    Mac=MD5
      RC2-CBC-MD5                Kx=RSA        Au=RSA     Enc=RC2(128)     Mac=MD5
      RC4-MD5                    Kx=RSA        Au=RSA     Enc=RC4(128)     Mac=MD5
      EDH-RSA-DES-CBC3-SHA       Kx=DH         Au=RSA     Enc=3DES(168)    Mac=SHA1
      DES-CBC3-SHA               Kx=RSA        Au=RSA     Enc=3DES(168)    Mac=SHA1
      RC4-MD5                    Kx=RSA        Au=RSA     Enc=RC4(128)     Mac=MD5
      RC4-SHA                    Kx=RSA        Au=RSA     Enc=RC4(128)     Mac=SHA1
      EDH-RSA-DES-CBC3-SHA       Kx=DH         Au=RSA     Enc=3DES(168)    Mac=SHA1
      DHE-RSA-AES128-SHA         Kx=DH         Au=RSA     Enc=AES(128)     Mac=SHA1
      DHE-RSA-AES256-SHA         Kx=DH         Au=RSA     Enc=AES(256)     Mac=SHA1
      DES-CBC3-SHA               Kx=RSA        Au=RSA     Enc=3DES(168)    Mac=SHA1
      AES128-SHA                 Kx=RSA        Au=RSA     Enc=AES(128)     Mac=SHA1
      AES256-SHA                 Kx=RSA        Au=RSA     Enc=AES(256)     Mac=SHA1
      RC4-MD5                    Kx=RSA        Au=RSA     Enc=RC4(128)     Mac=MD5
      RC4-SHA                    Kx=RSA        Au=RSA     Enc=RC4(128)     Mac=SHA1

Of course Nessus can be used to scan a local network to look and report this sort of information, but so can the nasl tool. Instead of supplying a target IP address, a network mask or range can be used such as:

nasl -t someScript.nasl

This will run your script on many different hosts and report results accordingly. This can be very useful to test many different types of targets and ensure that your plugin logic is correct.

Example Network and Credentialed Plugin Check

For our next example, we will look at the iTunes 6.0.5 vulnerability. There are two checks for this, a network check and a credentialed check. Running the network check is very straightforward:

[[email protected] plugins]# /opt/nessus/bin/nasl -t itunes_605_banner.nasl
[[email protected] plugins]#

There were no results found. Let's try the credentialed version of this check (itunes_605.nasl). This time, let's use the '-T' option of the nasl binary. This option traces each API used and its results to either a file , or use the minus sign for standard output. Here is an example trace:

[[email protected] plugins]# /opt/nessus/bin/nasl  -t -T - itunes_605.nasl
(TRACE) call #nasl_str2intarray(.91)!....:2*"....;3+#....<4,$?7/'....>6.&....=5-%........ )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(.........................)4.%/7.(3-!0,1'8"5.*2$.  )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(.:2*"....<4,$....>6.&[email protected]( ...91)!....;3+#....=5-%....?7/'.... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(. ............................................. . )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(..................... ........... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(.([email protected] './.7.?.&...6.>.%.-.5.=.$.,.4.<.#.+.3.;.".*.2.:.!.).1.9. )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(................. )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(........................................... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(................................................. )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(................................................. )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(......................................................... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(......................................... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(......................................... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(......................................... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(......................................... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(......................................... )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(................................................................. )
(TRACE) ret -> <array>
(TRACE) call #nasl_str2intarray(................................................................. )
(TRACE) ret -> <array>
(TRACE) call get_kb_item(SMB/Registry/Enumerated )
(TRACE) ret ->
(TRACE) call exit(0 )

The key to understanding this trace is the last call to the get_kb_item() API. This NASL script is expecting to find a user name and password stored in the knowledge base and when it doesn't it exits immediately.

We'll consider working with the KB in a moment, but first let's discuss modifying the actual script to hard-code some credentials. I don't advise hard-coding credentials located in the Nessus plugins directory. Copying the script to a new directory and editing it there will avoid re-using any edited plugins for production scans. If you end up working on live plugins keep in mind that a new plugin update may overwrite your  changes. Also if you create a local copy of a plugin, it will have the same Nessus ID or plugin name as before and this will cause problems if Nessus attempts to use both scripts.

To hard-code credentials into the itunes_605.nasl plugin, you can edit the section of code which queries the KB for scan information such as shown below:

# Connect to the appropriate share.
#if (!get_kb_item("SMB/Registry/Enumerated")) exit(0);

name    =  kb_smb_name();
port    =  kb_smb_transport();
if (!get_port_state(port)) exit(0);
login   =  "Administrator";
pass    =  "password";
domain  =  kb_smb_domain();

Notice that the line invoking the get_kb_item() API has been commented out and that the login and pass variables have been given fixed values. Here is an example run:

[[email protected] plugins]# /opt/nessus/bin/nasl -t /home/rgula/blog/itunes_605.nasl
[[email protected] plugins]#

There was no output this time since no vulnerabilities were found. Using the '-T' option to trace this edited program though would provide a much different output than before. I won't list the trace here, but each API invoked for logging into the remote machine, checking for iTunes and then gracefully closing the Windows SMB connection would be itemized.

Working With the Knowledge Base

For plugins which have multiple dependencies, running the nasl binary with the '-k' option can allow it to retrieve data from previous scans. In order to do this, you must perform a scan and have the results, including data learned during the scan, saved to the knowledge base (KB).

The KB is stored in the /kbs directory under the name of the Nessus user which performed the scan. For example, while writing this blog entry, my Nessus scanner didn't have any existing data for the 192.168
network for the 'nessus' user:

[[email protected] rgula]# ls /opt/nessus/var/nessus/users/nessus/kbs/192/168/*
ls: /opt/nessus/var/nessus/users/nessus/kbs/192/168/*: No such file or directory

To create a KB entry, configure a nessusrc file with credentials for a host to scan and also enable KB support with the "save_knowledge_base = yes" setting.

For this blog entry, I created a nessusrc scan policy that performed a full Windows patch audit, an invoked most Windows local security audits. After performing the scan (which isn't shown), we now have a KB:

[[email protected] rgula]# ls /opt/nessus/var/nessus/users/nessus/kbs/192/168/*

Now that the KB is in place, we can run almost any NASL script and just use the KB to feed information into our plugins.

Here is an example of running the smb_enum_softwares.nasl script which lists all installed software on a Windows host:

[[email protected] plugins]# /opt/nessus/bin/nasl -k /opt/nessus/var/nessus/users/nessus/kbs/192/168/20/ -t smb_enum_softwares.nasl

Synopsis :

It is possible to enumerate installed software.

Description :

This plugin lists software installed on the remote host by crawling
the registry entries in :

Solution :

Remove software that are not compliant with your company policy.

Risk factor :


Plugin output :

The following software are installed on the remote host:

Security Update for Windows Server 2003 (KB914388)  [version 1]
Security Update for Windows Server 2003 (KB928090)  [version 1]
(remaining output deleted)

Here is another example of a simple test for Microsoft bulletin MS07-017. This particular test was dependent on another plugin and is basing some of its analysis off of the results in the KB.

[[email protected] plugins]# /opt/nessus/bin/nasl -k
/opt/nessus/var/nessus/users/nessus/kbs/192/168/20/ -t smb_nt_ms07-017.nasl

smb_nt_ms07-017.nasl: Success

Our last KB example makes use of the new OS Fingerprinting NASL script. This script is dependent on many other plugins. Invoking it with the KB from our last scan shows how the scan target of was fingerprinted as a Windows 2003 server.

[[email protected] plugins]# /opt/nessus/bin/nasl -k /opt/nessus/var/nessus/users/nessus/kbs/192/168/20/ -t os_fingerprint.nasl

Remote operating system : Microsoft Windows Server 2003, Standard Edition (English)
Confidence Level : 100
Method : SMB

The remote host is running Microsoft Windows Server 2003, Standard Edition (English)

Running the same script without the KB offers no results: 

[[email protected] plugins]# /opt/nessus/bin/nasl -t os_fingerprint.nasl
[[email protected] plugins]#

Example Compliance Scan

The last example of using the nasl tool considers running the various .audit files from the Nessus Direct Feed. Any of the .nbin files used in the Direct Feed can be executed by the nasl tool and fed credentials and scan policies from the command line.

In the example below, the nasl tool invokes the compliance_check_windows_file_content.nbin plugin, and the user enters the credentials and scan policy to be used.

[[email protected] plugins]# /opt/nessus/bin/nasl -t ./compliance_check_windows_file_content.nbin

            Windows File Contents Compliance Checks, version 1.0.11

Which file contains your security policy : ./content_credit_card.audit
Login : Administrator
Password : password
Domain :
"Determine if a file contains a valid American Express 15 Digit Card Number" : [FAILED]
- error message:
The following files do not match your policy :
Share: C$, path: \new folder\datatest.xls    (XXXXXXXXXXX1000)
Share: C$, path: \new folder\datatest.pdf    (XXXXXXXXXXX1000)
Share: C$, path: \new folder\datatest.txt    (XXXXXXXXXXX1000)
Share: C$, path: \share\new folder\credit-card-list.txt    (XXXXXXXXXXX1000)

This method also works with the Windows and UNIX configuration audits. This can be very useful for trying different types of .audit files settings, diagnosing custom .audit policies and testing connectivity.


The nasl tool can be used for many different types of Nessus plugin activities including writing new plugins, writing new .audit files and diagnosing Nessus results.

Previously we've blogged about the smbshell.nbin plugin. This is a good example of a  stand-alone application written entirely in NASL and invoked through the nasl tool.

Related Articles

Are You Vulnerable to the Latest Exploits?

Enter your email to receive the latest cyber exposure alerts in your inbox.

Try for Free Buy Now

Try Tenable.io


Enjoy full access to a modern, cloud-based vulnerability management platform that enables you to see and track all of your assets with unmatched accuracy. Sign up now.

Buy Tenable.io

Enjoy full access to a modern, cloud-based vulnerability management platform that enables you to see and track all of your assets with unmatched accuracy. Purchase your annual subscription today.

65 assets

Choose Your Subscription Option:

Buy Now
Try for Free Buy Now

Try Nessus Professional Free


Nessus® is the most comprehensive vulnerability scanner on the market today. Nessus Professional will help automate the vulnerability scanning process, save time in your compliance cycles and allow you to engage your IT team.

Buy Nessus Professional

Nessus® is the most comprehensive vulnerability scanner on the market today. Nessus Professional will help automate the vulnerability scanning process, save time in your compliance cycles and allow you to engage your IT team.

Buy a multi-year license and save. Add Advanced Support for access to phone, community and chat support 24 hours a day, 365 days a year. Full details here.

Try for Free Buy Now

Try Tenable.io Web Application Scanning


Enjoy full access to our latest web application scanning offering designed for modern applications as part of the Tenable.io platform. Safely scan your entire online portfolio for vulnerabilities with a high degree of accuracy without heavy manual effort or disruption to critical web applications. Sign up now.

Buy Tenable.io Web Application Scanning

Enjoy full access to a modern, cloud-based vulnerability management platform that enables you to see and track all of your assets with unmatched accuracy. Purchase your annual subscription today.



Buy Now

Try for Free Contact Sales

Try Tenable.io Container Security


Enjoy full access to the only container security offering integrated into a vulnerability management platform. Monitor container images for vulnerabilities, malware and policy violations. Integrate with continuous integration and continuous deployment (CI/CD) systems to support DevOps practices, strengthen security and support enterprise policy compliance.

Buy Tenable.io Container Security

Tenable.io Container Security seamlessly and securely enables DevOps processes by providing visibility into the security of container images – including vulnerabilities, malware and policy violations – through integration with the build process.

Get a Demo

Get a Demo of Tenable.sc

Please fill out the form below with your contact information and a sales representative will contact you shortly to schedule a demo. You may also include a short comment (limited to 255 characters). Please note that fields with asterisks (*) are mandatory.

Try for Free Contact Sales

Try Tenable Lumin


Visualize and explore your Cyber Exposure, track risk reduction over time and benchmark against your peers with Tenable Lumin.

Buy Tenable Lumin

Contact a Sales Representative to see how Lumin can help you gain insight across your entire organization and manage cyber risk.

Request a Demo

Request a demo of Tenable.ot

Get the Operational Technology Security You Need.
Reduce the Risk You Don’t.

Request a Demo


Continuously detect and respond to Active Directory attacks. No agents. No privileges. On-prem and in the cloud.