Back to Posts

Share this post

Perform a Nessus scan via port forwarding rules only

Posted by: voidsec

Reading Time: 4 minutes

This post will be a bit different from the usual technical stuff, mostly because I was not able to find any reliable solution on Internet and I would like to help other people having the same doubt/question, it’s nothing advanced, it’s just something useful that I didn’t see posted before.

During a recent engagement I found myself in a strange network position. I had to perform a Nessus credentialed and patch checks on some Windows server, I was in a vLAN while the servers were positioned not only in another vLAN but in the DMZ. The only way that I was able to access those servers were though a jumpbox positioned between main client’s network and the DMZ.

Network topology can be summed up with the following diagram:

Unfortunately, jumpbox host wasn’t simply routing the traffic from/to the DMZ, it was just allowing me to connect to it trough RDP and from the jumpbox open another RDP connection to the target servers.

On Reddit and in Tenable community forum there are multiple discussions oh how is possible to scan a “remote” host via SSH, proxies, SOCKS, VPNs and such but:

  1. None of the cases applies
  2. Pretty much none of the proposed solutions works (besides the SSH/VPN tunnel, with some limitations)

Now, before moving on the actual configuration let’s speak about some of the constraints:

  1. I had Nessus installed on a Windows Box
  2. Jumpbox and Target servers were Windows too
  3. No traffic forwarding was configured between the different vlANs

In order to solve all these limitations, I had an idea: apply a bit of pentest pivoting flavor, forwarding some ports on the jumpbox to the remote server but unfortunately, being both of them windows, Nessus were trying to scan the jumpbox instead of the target server; at that point it was clear that I was needing another machine.

How to perform a Nessus scan via port forwarding rules?

In order to scan a Windows host, the following two ports are a MUST: 139, 445

To gather more results here there are some additional ports that may be required for hosts to be scanned (not an exhaustive list):

  • TCP Port 22 – SSH
  • TCP Port 23 – Telnet
  • TCP Port 25 – SMTP
  • TCP Port 80 – HTTP
  • TCP Port 139 – SMB
  • TCP Port 389 – Standard LDAP Traffic
  • TCP Port 443 – HTTPs
  • TCP Port 445 – SMB
  • TCP Port 636 – SSL/TLS
  • TCP Port 3389 – RDP

Anyway, the first thing to do is to setup another (Linux) machine to forward traffic to some port to the Windows jump box, here the commands:

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p tcp --dport 139 -j DNAT --to-destination 10.3.18.29:65444
iptables -t nat -A PREROUTING -p tcp --dport 445 -j DNAT --to-destination 10.3.18.29:65445
iptables -t nat -A PREROUTING -p tcp --dport 3389 -j DNAT --to-destination 10.3.18.29:65446
iptables -t nat -A POSTROUTING -j MASQUERADE

On the Windows jumpbox we have to configure other port forwarding rules in order to forward the traffic to the target’s server:

netsh interface portproxy add v4tov4 listenaddress=10.3.18.29 listenport=65444 connectaddress=192.168.3.81 connectport=139
netsh interface portproxy add v4tov4 listenaddress=10.3.18.29 listenport=65445 connectaddress=192.168.3.81 connectport=445
netsh interface portproxy add v4tov4 listenaddress=10.3.18.29 listenport=65446 connectaddress=192.168.3.81 connectport=3389

We can then check if the rules were applied with the following commnds:

netstat -ano | findstr :65444
netsh interface portproxy show all

And finally remove all the configured rules:

netsh interface portproxy reset
netsh interface portproxy delete v4tov4 listenport=65444 listenaddress=10.3.18.29

In this way Nessus will try to scan the Linux machine but once it reaches ports 139 and 445 all the traffic will be forwarded to the jump box and from it to the target servers, allowing us to perform a credentialed scan without limitations.

PS: do not forget to remove all the port forwarding :)

 

 

Back to Posts