Oh that’s “just a Nessus scan” or that’s not a real pen test etc. is something that if you are in the infosec/cyber world for a few minutes you will probably hear.

It’s honestly a bit odd, some sort of way of diminishing something because a tool was used, which doesn’t really make a whole lot of sense given most activity involves using something that already exists (sure there are fields and scenarios where this isn’t true but I’m generalising).

So why are we as an industry obsessed with tools and obsessed with berating people for using them? It’s all rather odd.

It perhaps ties in with this Cyber Myth about penetration testing being the tool that’s good and useful in every scenario… I hate to break it to people, but it’s not the principles of security and it certainly isn’t the best/most appropriate “tool” in every scenario.

That said, as with all methods, tools and approaches you need to know it’s pros and its cons. For example, did you know that the Nessus HYDRA module doesn’t support brute force on RDP?

Well know you do!

https://www.tenable.com/plugins/nessus/families/Brute%20force%20attacks

I’m going to try and show that “vulns scans are good, stop treating them like they are bad” and look at how penetration testing etc. is not the only tool in the box for security assurance.

Vulnerability Scanning

“A vuln scan” much like “a pentest” isn’t really a thing either because there’s different types of vuln scanner and configurations that can be deployed. I’m clearly focusing on Nessus here, but the principle is the same. But first let’s look at what we might want to be testing for and see if it’s largely included:

Action	Already in Nessus
Ping the host	X
Traceroute the host	X
Run a TCP port scan (quick)	X
Run a TCP port scan (full)	X
Run a UDP Scan (common ports)	X
Check HTTP Banners	X
Check HTTP Methods	X
Check TLS protocols and ciphers	X
Check HTTPS Response Headers	X
Check HTTP CSP	X
Check for Open Redirect	X
Check for web apps and admin portals	X
Forced Browsing	X
Check for admin interfaces	X
Brute Force Auth on Common Protocols	X (there are limitations)
Check for common HTTP vulnerabilities	X
Identify common software applications and platforms	X
Identify version numbers	X
Identify vulnerabilities based on version numbers	X

As you can see there’s a lot of checks that are conducted using a vuln scanner and the above table doesn’t scratch the surface.

Nessus has thousands of plugins:

https://www.tenable.com/plugins/nessus/families

https://www.tenable.com/plugins/was/families

https://www.tenable.com/plugins/nnm/families

https://www.tenable.com/plugins/lce/families

There are for example (at time of writing) 1525 Web Server Plugins.

A real-world demonstration

To demonstrate this, I setup a very basic server online, it was a simple Windows Server 2022 Gen2 VM in Azure (UK South)

On the server I installed IIS, the rewrite module and configured HTTPS with a self-signed certificate (I was being lazy to install Let’s Encrypt).

The challenge was, is it possible to gain a shell on this system?

Let’s think about this, I’ve got a static HTML site, two ports exposed both to IIS on a fully patched Windows Server 2022 system. Sure, there might be some 0-day vulnerabilities, but 99.9% of the world don’t have access to them if they did exist for this configuration, so what really is there to attack (if we remove denial of service etc. from scope – which is common to not be in scope).

Will manual testing really show me as the system owner a great deal more than if I ran a few appropriately configured Nessus scans?

Given I’m the system owner, I can say this, there’s hardly any additional value I’d get from a black box external perspective from manual testing (infra) and from a web testing perspective because I know what the web server holds (nothing!) the same would be true from an outcome perspective from a web pov.

I’m not saying manual testing isn’t useful at all here, far from it, but it’s not going to change the outcomes here compared to running some vulnerability scans.

As of 02/08/2022 the server is still online, but clearly, I won’t keep it there forever. But the premise of this box, well it’s not a CTF, there are no flags, there is nothing particularly exploitable (that we know of!).

For this server I’m quite happy with running a Nessus scan, I’d also be happy if someone showed me the manual testing and what was and was not found, but honestly, I wouldn’t be overly worried if it was one or the other, hell if you were going to manually test this you would probably run a few Nessus scans in the background anyway!

For anyone interested the Nessus Scan Report is here:

PwnDefend-Demo_7bwgig

Is this the end?

Well, no, I mean, look as the system owner, architect and operator (lucky me!) I need to be aware of a great many things, and simply put, a pen test from an external perspective is always going to give me a limited view at best, so what else could we do?

• Design Review
• Process Review
• Configuration Review
• Code Reviews
• Data Flow modelling
• Threat Modelling
• Risk Modelling/Reviews
• Control Testing
• Vulnerability Assessments
• Penetration Testing (white box/grey box/black box)
• Red Teaming
• Purple Teaming
• Monitoring and Alerting Testing
• Incident Response Reviews
• Assumed Breach Testing

There’s a lot more to the world than penetration testing, but for some reason as an industry it seems penetration testing is put on a pedestal. Which is odd because with many organisations, they seem to want the fastest, cheapest penetration test possible to just tick a box. Both things are not good, as they do not really support the outcome of a more secure, resilient, and safer society, organisations or systems.

GAPS

What’s important in this is to realise the pros and cons for different approaches, methods, and tools. Security is never one and done, it’s always an evolution and a journey. You also aren’t always aiming to find 0 days, sometimes the aims are to assure your controls are effective and functioning as expected, or simply to identify gaps.

What gaps can we find in the demo scenario?

• A fast one is the lack of CDN and Web Application Firewall.
• The target has EDR deployed but doesn’t have centralised web application log monitoring (there is no SIEM).
• The certificate is self-signed.
• The server OS and platform (IIS) do not have specific hardening deployed.
• Automatic Updates are set to manually install.

Summary

Choosing a penetration test in a large number of scenarios might not lead you to the best security outcomes, also the scoping of said pentest will also greatly affect the security outcomes, if you aren’t starting with a white box approach you are probably taking the wrong path (if you are even at the point where you should “run a pentest” is another question).

There’s a lot more to be done to secure an organisation or system than a penetration test, look don’t get me wrong pentesting can be a super valuable activity, but largely I see it being deployed as some sort of check box or silver bullet, and well that’s not really going to help you holistically that much. So, my advice is to think about the security of a service or system as a whole, think about what you have done from a defender perspective and think about the outcomes you are after. If you are after a compliance tick box and a cheap test, that’s ok, just don’t expect shells to be raining down. Pen testing uses science does not magic. Security testing is far more than “just a pentest”. Hopefully this post has helped shed some light on the pros and cons of vuln scanners as well as showing options for revieing the security of a system that goes far beyond “just a pentest”. And remember, sometimes running a vuln scan really is a good thing, you just need to apply some thought to the process (and remember there no silver bullet, just doing one thing with security is largely not a good idea!)