Vulnerability Management, Assessments and Vulnerability scanning is sometimes treated a with distain in the Offensive security community, I personally don’t understand that. Vulnerability management is key to inputting into security strategy, architecture, and operations. It’s coupled heavily to many other processes such as:

  • Asset Management
  • Risk Management
  • Patch Management
  • Change & Release Management
  • Security Testing
  • Security Monitoring

Before we start deploying let’s think about some areas for consideration when performing vulnerability scans:

  • Scope
    • Asset/Hosts
      • IP Ranges
      • Hostnames
    • Connectivity
      • VPNs
      • LAN/WAN
    • Device Types and Configuration
      • Domain
      • Workgroup
      • Appliance
      • ICS
      • Printers
      • Network Equipment
    • Unauthenticated View
    • Authenticated View
      • Auth Types
      • Protocols
    • Scheduling
    • Authority to execute
  • Impact
    • Performance
    • Availability
    • Confidentiality
  • Objectives and Outcomes
  • Reporting
    • Information Flow
    • Report Storage and Confidentiality

I’m not going to go into detail on all these areas, hopefully it’s obvious but if not shout at me online and I’ll write more about this part. Just please, please don’t think “it’s just a scan”, this isn’t like you click one button and the job is done. Outside of scanning isn’t that simple to start with, you also need to realise vulnerability identification is just one part of vulnerability management. Once you have the outputs they need to be understood, contextualised and they need to feed into risk management, vulnerability management, patch management etc. Treating this as “just a scan” is a sure-fire way to not enable business value from these activities. Now we’ve got that part over, I want to dive into the configuring of scans and looking at the outputs! (The fun stuff!). First off let’s get an appliance deployed.

OVA Deployment

Ok so we can deploy Nessus on Linux, OSX and Windows. We can install on top of an OS or use appliances from Tenable. For this blog I’m doing to deploy using the appliance for simplicity.

Graphical user interface, text, application, email

Description automatically generated

Once the OVA has been deployed you need to power on the VM.

Text

Description automatically generated

In this example the appliance is on a segment with DHCP.

Graphical user interface, application, Word

Description automatically generated

We now use a web client to browse to the appliance:

The default credentials are:

wizard:admin

(Red Team/Penetration testers take note of this as if you find an appliance and someone hasn’t configured this default creds could give you root access).

Graphical user interface, application

Description automatically generated

Now create a new username and password (must be 14 characters and complex)

Graphical user interface, application

Description automatically generated

Now we log in:

Graphical user interface, application

Description automatically generated

Graphical user interface, text

Description automatically generated

We can configure our appliance management system here. This is essentially a cockpit for the appliance a bit like this: https://cockpit-project.org/

The application services are running on a web service on TCP 8834

https://10.0.0.59:8834/#/

Graphical user interface, application, website

Description automatically generated

Click CONTINUE then enter your activation code:

Graphical user interface, website

Description automatically generated

Click CONTINUE then create a user account:

Graphical user interface, website

Description automatically generated

Graphical user interface, application, website

Description automatically generated

Graphical user interface, application

Description automatically generated

Now go and make a tea/coffee.

Graphical user interface, application

Description automatically generated

Ok cool, now we’ve had 2 cups of tea we are ready to get configuring!

Now we should consider the purpose of this scanner, for here we are going to emulate this being used on a short-term vulnerability assessment or penetration test, so I’m not going to configure SMTP integration (I can check back when scans are complete etc).

To start we are going to create a quick Host Discovery scan:

Let’s click NEW SCAN then select the Host Discovery template:

Graphical user interface, application

Description automatically generated

Now we need to configure this, so let’s give it a name, description and target range.

Graphical user interface, application, Teams

Description automatically generated

We are going to review/configure the DISCOVERY parameters:

Graphical user interface, text, application, email

Description automatically generated

I’m going to change this to include a common port scan. As we know to discovery network assets requires a mixture of techniques. We aren’t trying to be stealthy here, our goal is to find as many assets and services as possible.

Graphical user interface, text, application, email

Description automatically generated

So, let’s click save, then move to REPORT:

Graphical user interface, text, application, email

Description automatically generated

Now here we can choose some options, the main one we will probably configure here is the PING option and DNS name options. For the lab I’m going to enable reporting hosts by DNS name and then we are going to look at advanced:

Graphical user interface, text, application, email

Description automatically generated

Here we have some options around scanning, we don’t know this network (Ok I do but I’m pretending I don’t), so we are doing to enable Slow down the scan when network congestion is detected:

Graphical user interface, text, application, email

Description automatically generated

We are going to save the options. Next, we need to run the scan:

Graphical user interface

Description automatically generated with medium confidence

Click LAUNCH

Graphical user interface, text, application

Description automatically generated

And 3 minutes later (remember this is a tiny single /24 network in a lab) our scan is completed:

Graphical user interface, text, application, email

Description automatically generated

We can see here the DHCP server in the lab is giving out a DNS server that is unaware of the directory services reverse lookup space (we can see there is a domain controller running on 10.0.010 – look at the ports, 53, 445,389,636,88, 3268, 3269 screams domain controller). This is because the lab didn’t have a reverse dns lookup zone configured.

We are going to disable the report hosts via DNS flag so that IP’s are reported. Now this area is one that can be interesting so work with the report consumers to work out the best approach (the lab example isn’t common; you would usually get a domain linked DNS server provided):

Graphical user interface, text, application, email

Description automatically generated

Now we’ve discovered some hosts we have some options. Our next step is to move to an unauthenticated scan of the range. We do however have a choice; we can configure a scan for the whole /24 or we can use the discovered targets. We are going to go with option 2 in this instance. Let’s export the hosts:

Graphical user interface, application

Description automatically generated

Select CSV

Graphical user interface, application

Description automatically generated

We don’t need all the details for this but it’s useful from a reporting pov to export these:

Graphical user interface, text, application, email

Description automatically generated

Great we now have a CSV export. This output is one of the more useful ones in this instance. The PDF and HTML outputs in this instance aren’t going to blow you away:

A picture containing table

Description automatically generated

We have run a host discovery with common ports (now please bear in mind, discovery of assets and the constraints/parameters need to be understood).

Consider:

  • Network Topology
  • ACLs
  • Host Based Firewalls
  • Network Segmentation
  • ICMP
  • ARP
  • Protocol Impacts
  • IPS/IDS

For this run through we are going to continue with this list:

10.0.0.1

10.0.0.10

10.0.0.50

10.0.0.51

10.0.0.52

10.0.0.53

10.0.0.54

10.0.0.55

10.0.0.56

10.0.0.57

10.0.0.58

10.0.0.59

10.0.0.8

Basic Network Scan

Now Let’s create a BASIC NETWORK SCAN by navigating to My Scans then clicking New Scan:

Text

Description automatically generated with low confidence

Graphical user interface, application

Description automatically generated

We select Basic Network Scan:

Logo, company name

Description automatically generated

Graphical user interface, text, application, email

Description automatically generated

Now we are going to enter the details:

Graphical user interface, application

Description automatically generated

For this scan we are going to do full port scans:

Graphical user interface, text, application, email

Description automatically generated

We are going to leave assessment with DEFAULT:

Graphical user interface, text, application, email

Description automatically generated

On Report we are going to configure Override normal verbosity and report as much information as possible:

Graphical user interface, text, application, email

Description automatically generated

And we are going to leave the scan type as default. Again, tune this configuration to suit your network environment and risk appetite.

We are now going to run the scan:

Graphical user interface, application

Description automatically generated with medium confidence

Now that’s running we can monitor this, there’s views of HOSTS and VULNERABILITIES:

Chart, bar chart

Description automatically generated

The scan status is shown on the right-hand side.

After around one hour, the scan has completed!

A screenshot of a computer

Description automatically generated

Yay job done, isn’t it? Nope. Not so fast. That was just an unauthenticated scan, but also it needs to be read and understood. This is the part the world needs to wake up to a bit, security management takes time. But before we start analysing the outputs let’s kick off another scan, this time we want to authenticate. Here we create a new scan, this time using the Credential Based Patch Audit scan template (you can add credentials to more than this template):

Graphical user interface, application

Description automatically generated

We are going to provide the scan domain admin credentials. You need to consider the scan authentication process, the security of the scanner but also the levels of access required. To audit active directory domain controllers, we will need local admin right on the domain controllers. Authentication is an area that can take far more time than people realise. For scans to be successful the targets must also be in a certain configuration. Workgroup machines are also ‘fun’ to configure and to scan, they are often painful to access let alone to scan.

Chart, bar chart

Description automatically generated

This authenticated patch scan (common ports) tool 11 minutes. Whilst we kick off another full range port scan, let’s start to look at the output.

We can see already this doesn’t look good. A few challenges will immediately stand out, currently we don’t really have a way of contextualising the business purpose of each host. Now we can use reverse lookups and often server names might help but in some orgs the names aren’t meaningful. Instead, we would need to either, contextualise with other data (this could be from an asset management system or by speaking to someone in the ops team) or we can review the fingerprints and service makeup.

A screenshot of a computer

Description automatically generated

The next thing that might scream out to you is, hell there’s a lot of findings. So here again we need to consider, which hosts have a “full” picture and did any scans fail, so we can search for fail:

Background pattern

Description automatically generated with low confidence

Graphical user interface, text, application, email

Description automatically generated

Here we have two hosts that failed to scan fully. It’s important to review the scans and identify failures as well as locating information to enable you to understand the scopes vulnerability landscape.

Making Sense of it all

The easy answer to this might be “deploy patches” and there’s some features of Nessus (and other vulnerability scanners) to help this.

Graphical user interface, text, application, email

Description automatically generated

In the remediation tab there are 50 actions. We must remember though that we should consider different perspectives:

  • Reviewing the environment
  • Operating the environment
  • Remediating the vulnerabilities

It’s important to look at context, priority, and impact/effort to fix etc. Looking at critical and highs isn’t a bad idea, but we must again remember a few things, this won’t find all vulnerabilities, there may be false positives and, exploits can be chained.

Key Considerations

Outside of understanding the vulnerability class, type, severity, exploitability, and exploitation availability information there’s a whole load of other things that are important. Now I’m sure some people will be reading thinking “that’s not my problem, but that’s exactly why the world is currently a hot mess. It’s key to ensure that both the vulnerability landscape is understood but also the business context and risk. We need to consider questions such as:

  • What is the assets’ purpose?
  • Who is responsible for it?
  • Is it dev, test, or prod?
  • Are there any special considerations?
  • When are maintenance windows?
  • What are the impacts of the changes that mitigate the vulnerability?
  • Are there supplementary controls that can be deployed?
  • How does all of this create a picture of prioritisation for remediation?

Vulnerability scanning is part of the vulnerability management process, it also ties into a much wider security architecture view (as well as obviously from an operational perspective). Fundamentally vulnerability management interfaces with a large area of security and risk management (you know part of managing technology and risk) so it’s important to consider the inputs, outputs, processes, constraints, activities, and flows.

Whether you like to cite a process from a cyberz framework (e.g. https://csrc.nist.gov/publications/detail/sp/800-40/rev-3/final) or whether you are a fan of the many many many variants of PDCA (like OODA) the reality is vulnerability management (and basically most other things in security and technology management are iterative.

The NCSC wheel for VA is:

https://www.ncsc.gov.uk/guidance/vulnerability-management

The key points I’m making here is that you need to be constantly checking, reviewing, and planning. There are loads of variations on a theme. The key things to me are:

  • Understand your business context
  • Understand your network and assets
  • Understand the risks
  • Be realistic
  • Communicate
  • Remember this isn’t simple and it’s not solved by ‘just patching’

I hope this blog post is useful to some. It’s really a tiny dive into not just the process of scanning networks but also looking at the wider picture. It’s very easy for people to abstract and silo. I think it’s important for security practitioners to understand both some of the details but also how all of this fits together, even if you aren’t the one running scans and interpreting the raw outputs.

Leave a Reply

Your email address will not be published. Required fields are marked *