Vulnerability Management with Nessus: Discover and Remediate System Weaknesses Before They're Exploited
Colton Hicks
Cybersecurity Professional | SOC Analyst | Passionate About Cloud Infrastructure, Incident Response & Vulnerability Management
Every IT asset we bring into our environment?—?whether a new system, network, or application?—?pushes the boundaries of what we can accomplish.
But each one also expands our attack surface and introduces security vulnerabilities. It’s like securing a house. We must be mindful that its many doors and windows, while necessary, open up attack vectors for unwelcome visitors.
We’ll want to address these vulnerabilities before the troublemakers can exploit them.
That’s the purpose of Vulnerability Management, the process of discovering and remediating system weaknesses before they’re exploited.
In this project:
Without a Vulnerability Management function, attackers can slip through the cracks and wreak havoc on our IT systems.
Preparing for Nessus Scans: Setting Up a Virtual Environment in?Azure
The first thing we need to do is create our lab environment.
We’ll use Azure to spin up a couple of Virtual Machines. This is a cost-effective platform where we can deploy VMs without the overhead of traditional virtualization. It also isolates the project environment from our local system (reducing security risks).
Here’s what we’ll set up:
I’ll start with the analyst Windows VM. This is where Nessus will be installed, and we’ll be doing all our scanning from there.
Go to the “Virtual Machines” service in Azure’s portal and create one.
I’ll make sure all these details are met:
Review and create.
Next we’ll install Nessus onto our analyst Windows VM.
Nessus is a popular vulnerability scanner trusted by security professionals. It’ll uncover weaknesses in any endpoint it’s connected to. Log into the VM, open Microsoft Edge, and search for the Nessus download page. Or, we can click HERE .
We’ll choose the latest version of Nessus and select “Windows?—?x86_64” as the platform.
After clicking the download button, we’ll be required to agree to the license agreement
Click “Agree.” The file will download into our File Explorer, waiting for us to install it.
It’s always a good idea to create a file hash of the downloaded file and compare it with the checksum.
A file hash serves as the file’s unique fingerprint, a sign that the file’s integrity hasn’t been compromised. It’s generated from the file’s contents. We can compare it with the file hash provided on Nessus’s download page?—?the checksum?—?to ensure no tampering occurred during the download process.
Go to the “Downloads” directory in Powershell and use the ls command to see the Nessus downloaded file. Then, create its file hash with this command:
Get-FileHash?.\Nessus-10.8.3-x64.msi
Now we can look at the checksum on the Nessus download page to make sure the SHA256 hash matches.
Great. This verifies that the file’s integrity is intact and matches what Nessus provided.
It’s safe to install it on our analyst VM. So let’s do that.
Once Nessus is installed, we’ll be taken to a web-based graphical user interface (GUI).
This is where we’ll configure, run, and review vulnerability scans. We’ll access the Nessus service via https://localhost:8834/#/. The term “localhost” directs our web browser to services running on our own machine. And Nessus listens on port 8834.
So, when we enter that URL, we’re requesting the Nessus service on the host machine we’re using.
Connect via SSL to continue.
We’ll get a warning that says the connection isn’t private. That’s fine. Click “Advanced” and continue to the local host.
We’ll register for Nessus Essentials?—?it’s the free version.
Next we’ll be asked for our name and email. After submitting it, we’ll get an activation code. Save it in a document in case we need it later.
Then create a username and password for the Nessus administrator user account.
Once that’s done, Nessus will need a bit of time to get everything up and running.
Eventually we’ll be greeted by the home page of the Nessus portal.
Take note of the spinning icon in the top-right corner. That’s Nessus compiling plugins, so we’ll need to wait for this process to complete before we can proceed.
Once the plugins are compiled, our Nessus Vulnerability Scanner is ready for use.
Finally, let’s create a vulnerable Windows VM that we’ll scan later.
This allows us to simulate real-world vulnerabilities for testing and analysis. In Azure’s portal, I’ll navigate to “Virtual Machines” and create a new one. Let’s put the VM in the same resource group, region, and Vnet as the analyst VM. I’ll also give it the same VM size and Windows 10 Pro image.
Set up a username and password for the admin account.
Review and create.
Next we’ll RDP into our vulnerable Windows VM, disable the local firewall, and install outdated software to give it extra vulnerabilities for future scans.
The first step is to disable the local firewall so the vulnerability scanner can connect to our VM without any network barriers. While this approach is suitable for a controlled testing environment, in a production environment there are more secure methods to connect them (e.g. being a part of the domain).
Go to wf.msc and turn the firewall off for the domain, private, and public profile.
Done. Now I’ll download an old version of VLC player, Firefox, and Adobe Reader on the machine.
Install each, starting with VLC media player.
Repeat the process for each application.
Now all the old software versions are installed on the Windows VM, making it more vulnerable.
Our lab environment is ready.
It’s time to start our journey into Vulnerability Management, where we confront the hidden weaknesses within our VM.
The 5-Step Vulnerability Management Lifecycle
So what is a vulnerability?
It’s a weakness in a system. It’s something a threat actor can exploit, break into, or compromise. Understanding vulnerabilities matters because they’re entry points for attackers. Think of a weak lock that intruders can easily break into.
In computer systems, something like unpatched software or misconfigurations can be that weak lock, giving threat actors a way to cause damage or gain access.
Vulnerability management is the process of finding and fixing those weaknesses.
In an organization, the goal is to reduce risk to an acceptable level and keep it that way. Vendors do this all the time with automatic updates for our phones and computers. They’re fixing vulnerabilities on our behalf.
But what if we wanted to handle vulnerabilities ourselves?
Then we’d want to follow the Vulnerability Management lifecycle.
We’ll use a five-step process that closely aligns with the NIST Cybersecurity Framework (CSF) , a highly respected set of guidelines for managing and mitigating cybersecurity risk. It’s worth noting that the “protect” function of the NIST CSF isn’t included in this lifecycle. This function focuses more on preventative controls like firewalls, encryption, and access management?—?things that aren’t the main focus of vulnerability management.
Here are the 5 Vulnerability Management lifecycle steps:
In a real-world scenario, you’ll likely manage multiple endpoints.
Step 1 is important when there are many assets within an organization. It ensures the most critical systems are addressed and protected. Since we’re only scanning a single vulnerable machine, we’ll briefly go through this step.
The bulk of our project will involve steps 2 to 5 of the Vulnerability Management lifecycle.
Step 1: Discover & Prioritize Assets Based On Their Importance
The first step is to identify assets within our network?—?servers, workstations, and any other network endpoints.
This gives us a clear picture of what needs protection. Once we’ve found all the assets in our IT infrastructure, the next realization hits: Not all assets are created equal. Some pose greater risks, some are more crucial to keeping the business running, and some hold sensitive data. We need to prioritize asset vulnerabilities that matter most to an organization.
In our case, we’re only dealing with a single vulnerable machine, so we can proceed to the next step.
Step 2: Assess Vulnerabilities with Uncredentialed and Credentialed Scans
Next we’ll run thorough vulnerability assessments to find weaknesses in our vulnerable Windows VM.
There are two types of scans we’ll use:
We’ll start with an uncredentialed scan.
Make sure we’re logged into our analyst VM and go to https://localhost:8834/#/ on our web browser. Sign in to our Nessus admin account.
Create a new scan and select “Basic Network Scan.”
Fill out the name and description.
We can leave the default folder as it is. Make sure the vulnerable VM’s IP address is set as the target in the configuration.
Now we can try running the scan.
But notice we don’t see any results.
Recall when we set up our lab environment, we disabled the local firewall so our vulnerable Windows VM can connect to the Nessus scanner.
Let’s try pinging our VM to make sure the connection is intact.
Notice how the first ping was timing out and we couldn’t connect to the VM.
This is because I’m using Azure for my vulnerable Windows VM. So by default, there’s an extra cloud firewall?—?called a Network Security Group?—?blocking the network connection. I need to create an inbound port rule in Azure to allow traffic from any port. Once the rule is added, we can connect, as you see in the second ping request.
Here’s the inbound port rule I used.
In a production environment, this isn’t a safe way to connect Nessus to our endpoints.
It’s much safer to use a domain controller. This is a central server that manages all the endpoints in a network (called a domain). When an endpoint is “on the domain”, it’s managed by this central controller and creates a safer way for Nessus to communicate with it. We have to take extra steps to grant Nessus access since our vulnerable Windows VM isn’t on the domain. This is why we’re opening up our ports.
Later we’ll manually adjust Windows security settings to allow Nessus to perform credentialed scans.
But for now, let’s run an uncredentialed scan.
Here are the results.
Uncredentialed scans are useful security checks.
They can only scan the system from the outside. So this simulates what an attacker would be able to see without any credentialed access to our system. They’ll be able to see things like open ports, running services, and other externally visible information.
We can select “Vulnerabilities” to see what the scanner found.
Nessus will give us a list of all the vulnerabilities with columns containing details.
There are 7 columns worth explaining:
Severity tells us how bad a vulnerability is.
It refers to how much damage it’d cause an organization if a threat actor exploited it. Knowing how severe a problem is helps us prioritize the most dangerous ones first. It’s ranked by Critical, High, Medium, Low and Info.
The “Info” level is the outlier?—?it focuses on system or network details we should be aware of, rather than the risk severity.
CVSS stands for Common Vulnerability Scoring System.
It’s a standardized framework used to rate the severity of a vulnerability, giving us a quantifiable way of comparing risk. The score ranges from 0 to 10. And a higher score means the problem is more dangerous.
We can use the CVSS to prioritize vulnerabilities.
VPR stands for Vulnerability Priority Rating.
Like CVSS, it gives a score to measure how bad a vulnerability is. But VPR scores are more dynamic. They update regularly, using real-time threat intelligence and the specific environmental context.
Both help us understand risk.
EPSS stands for Exploit Prediction Scoring System.
The purpose of EPSS is to estimate the likelihood of a threat actor exploiting this vulnerability. The score ranges from 0 to 1, with higher scores indicating a higher probability of exploitation. A high EPSS score isn’t necessarily a big security concern?—?for instance, the vulnerability may be on a non-critical system. The scores update regularly based on threat intelligence and trends.
It’s another tool we can use to prioritize our remediation efforts.
The name, family, and count columns are straightforward.
The name tells us the title or description of the vulnerability. The family tells us the group or category that this problem belongs to. And the count tells us how many times this problem appeared on the system.
We’ll save our remediation tasks for our credentialed scan since it’ll find more vulnerabilities.
But let’s look at one of the informational vulnerabilities before moving forward.
Here, Nessus recognizes our vulnerable Windows VM has authentication set up.
领英推荐
So it tried logging in to check for vulnerabilities. It failed though?—?this is expected since we’re running an uncredentialed scan. If we give Nessus the ability to access our vulnerable VM, then it can look deep inside our machine and give us more intel.
Let’s do that now.
We’re going to:
Let’s start by making sure our vulnerable Windows VM can accept authenticated scans.
Since our VM is off the domain, we need to manually configure certain settings for the scanner to work. RDP into our vulnerable Windows VM to log in. We’ll start by enabling the remote registry so Nessus can connect to the computer’s registry and scan it for potential security issues.
Go to Windows Services. We can enable it by making the “startup type” automatic. Press OK.
If it’s still not running, you may need to double-click the remote registry again and click “start” (as it’s greyed out in the image above).
It’ll look like this when it’s running:
Next we’ll make sure file and printer sharing are turned on.
File and printer sharing allows other devices on the network to access shared files and printers on the machine. It’s important for the vulnerability scanner to check security issues related to these services.
We can check this in the control panel under Advanced Sharing Settings.
We’re good to go there.
Now we’ll go to User Account Control (UAC) Settings and make sure it’s set to “never notify.”
UAC is a security feature that asks for confirmation when system changes are made. Disabling this ensures that Nessus can scan our VM without any interruptions.
Now we’ll open the Windows Registry and add a key to enable remote access and further disable User Account Control settings. This will give the remote user account (which Nessus will use) permission to scan our system without UAC blocking it.
Locate the following registry subkey in the Registry Editor:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
This subkey contains important settings that control how Windows manages system policies, including remote access and user account control. We’ll need to add the registry entry LocalAccountTokenFilterPolicy as a key here. Adding this key allows for remote access without requiring additional UAC prompts.
On the Edit menu next to the registry keys, perform a “Right-Click” and click on “New”. Select “DWORD (32-bit) Value” and type in the key.
Now it’s added.
Right-click on LocalAccountTokenFilterPolicy and click "modify". In the Value data box, type “1” and click OK.
Setting the value to "1" enables the filtering policy, allowing the remote user account to bypass UAC restrictions
Exit Registry Editor and restart the virtual machine so the changes take effect.
We’re ready to add credentials to Nessus so it can run a credentialed scan. Go back to our analyst VM and navigate to the Nessus scan page.
Select “Configure.”
We’re going to add our vulnerable Windows VM credentials here.
Let’s also make sure we’re scanning all ports.
Save the new configurations.
Now we’ll run our credentialed scan.
After 15 minutes, we get the results.
It’s much more comprehensive than our uncredentialed scan.
Great. We’ve scanned everything accurately and efficiently.
Let’s report and remediate our vulnerabilities.
Step 3: Report & Remediate High-Priority Vulnerabilities
Within a Vulnerability Management function, it’s important to report vulnerabilities to the right team for remediation.
It’s about turning scanned data into clear, actionable steps. It ensures vulnerabilities are tracked and addressed. The report itself should list the vulnerabilities found and, ideally, offer guidance on what to prioritize and how to fix them. There are several ways to create this report.
Since we’re remediating the vulnerabilities in our own environment, let’s keep it simple and use Nessus’ built-in reporting features.
Go to the page where you want to create a report, then select “Report” in the top-right corner.
Choose a template you’d like to use.
I’ll select the default one.
Once generated, we’ll get a basic report we could send to the remediation team.
Vulnerabilities are organized by host and severity. Clicking “Show” would display a comprehensive list of issues that need to be addressed.
Now that we’ve reported the vulnerabilities, let’s address the critical and high severity issues first (the same way an organization would prioritize the most urgent issues).
I’ll return to the “Vulnerabilities” page in Nessus for the rest of this section.
The top 4 vulnerabilities are tied to old or deprecated software versions installed on our vulnerable Windows VMs?—?Firefox, VLC media player, and Adobe Reader.
Deprecated software applications no longer receive security updates or patches from the vendor.
This makes them exploitable in multiple ways?—?remote code execution, privilege escalation, Denial of Service (DoS) attacks, information disclosure, and more. They make up all our critical severity vulnerabilities in Nessus, and many of our high severity ones.
We can remediate them by simply uninstalling or updating the software applications.
I’ll uninstall them.
Let’s RDP into our vulnerable Windows VM and go to the control panel. Select “Uninstall a program” underneath “Programs.”
Start by uninstalling Adobe Reader.
Repeat for Firefox and VLC media player.
Now they’re all gone from our system.
Next let’s remediate the remaining high severity vulnerabilities in our environment.
First, we’ll focus on the WinVerifyTrust Signature Validation Vulnerability (CVE 2013-3900 ).
In Windows systems, the WinVerifyTrust function checks if files are safe.
A Portable Executable (PE) file carries instructions for a computer program. And each of these files has a digital signature to ensure they come from a trusted source. A part of this signature includes a digest?—?a summary or “fingerprint” of this executable file. However, in our vulnerable Windows machine, this file-checking function isn’t properly verifying the file’s digest. An attacker could exploit this by altering the PE file in a way that doesn’t invalidate the digital signature. In other words, an attacker could deploy harmful instructions to our computer, and the WinVerifyTrust function wouldn’t flag it as dangerous.
It’d be like receiving a sealed package that looks untouched?—?but inside, someone has secretly added something dangerous without breaking the seal.
To fix this issue, Microsoft provided updates and patches for affected versions of Windows.
So we should be able to remediate this by doing some Windows security updates in our vulnerable VM.
After installing some updates, we’re prompted to restart the machine. I’ll do that. Then I’ll RDP back into the machine and check for more updates. We’ll keep doing this?—?installing updates, and restarting the machine?—?until everything is up-to-date.
We’ll see a message like this when we’re finished.
Done.
Let’s look at one final high severity vulnerability underneath SSL issues.
There are 7 issues listed, so I’ll choose the only one ranked as a high severity one.
This is the SWEET32 vulnerability (CVE-2016–2183 ).
Our vulnerable Windows machine is using an older type of encryption called Triple-DES and is no longer safe to use. Triple-DES uses 64-bit blocks, a relatively small size by today’s standards, which makes the encryption more vulnerable.
Encryption is a way of hiding sensitive information so only the right people can see it. It scrambles data in a way that appears random to prying eyes. But weak encryption can be exploited. Hackers can use a birthday attack to flood the system with data and find two pieces of encrypted data that match.
This match is called a collision. And once hackers find a collision, it leaves clues for how they can crack the encryption and steal important information (like session cookies or passwords).
In less than 2 days, experts were able to retrieve a session cookie using a birthday attack on a system using Triple-DES encryption.
First, let’s confirm that our vulnerable Windows VM is using Triple-DES encryption.
We’ll use Nmap (Network Mapper) to verify this. Nmap is a tool to scan for services running on a host, its open ports, and various network details. We’ll use it to check which SSL/TLS ciphers are being used on our vulnerable VM. A cipher is simply an algorithm used to encrypt data.
Assuming Nmap is installed on our analyst VM, we can run this command in Powershell:
nmap --script ssl-enum-ciphers <target_host>
The --script ssl-enum-ciphers tells Nmap to run a script called ssl-enum-ciphers?, which displays the encryption ciphers our target host is using.
We can see ms-wbt-server is running on port 3389/tcp and open to traffic.
This traffic is using Remote Desktop Protocol (RDP) for Microsoft. We can see one of the encryption ciphers in use is TLS_RSA_WITH_3DES_EDE_CBC_SHA. This indicates that our vulnerable VM is using Triple-DES encryption.
Nmap also gives it a “C” security grade, indicating it’s a weaker encryption cipher.
To remediate this, we’ll remove 3DES in our vulnerable VM’s Registry Editor so only strong ciphers are enabled.
Let’s RDP into our vulnerable machine.
Open the Registry Editor and go to:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\Default\00010002
Double-click on “Functions” and remove TLS_RSA_WITH_3DES_EDE_CBC_SHA. Press OK.
We’ll also want to delete it from the registry tree on the left.
Click the drop-down arrow for 00010002 and scroll down to the correct encryption cipher. Right-click and delete.
Restart the vulnerable Windows VM.
Now when we run another Nmap scan, it’s no longer listed:
So we’ve successfully remediated the SWEET32 vulnerability by removing the 3DES encryption cipher.
Let’s verify all our remediation efforts worked.
Step 4: Verify All Remediation Efforts Were Successful
We need to verify our remediation efforts worked and confirm our systems are no longer at risk.
We’ll scan the system again to make sure the vulnerabilities are gone. And if Nessus still shows a critical or high severity vulnerability, we need to figure out why.
Let’s run a credentialed scan to confirm.
As you can see, we’ve successfully removed all the critical and high severity vulnerabilities.
Step 5: Improve Vulnerability Management Functions By Regularly Repeating the Lifecycle
Vulnerability management is an ongoing process.
Regularly repeating the lifecycle helps us adapt to new threats and protect our environment. One of the simplest ways to stay ahead is to set up automatic updates for Windows OS and third-party software. That way, we can keep our systems patched more regularly.
This will save us time and effort.
We can also schedule Nessus to scan our target hosts on a regular basis, making sure vulnerabilities are always detected and dealt with.
Through the recurring process of updates and scans, we establish a steady security practice?—?an assurance that our systems are protected.
Next Steps
Diving into Vulnerability Management with Nessus has been a fun journey.
This project took 20+ hours to implement and document. Every time I dive deeper into defensive cybersecurity, I uncover new insights that broaden my IT security capabilities. I enjoy passing on these discoveries to others who are also interested in the cybersecurity space.
If you enjoyed this content, you might like my in-depth project breakdown where I built a honeynet and SOC in Azure cloud.
In the content, I share:
The project took 100+ hours to implement and document.
Disclaimer: This project was conducted in a secure, isolated virtual environment. It is highly recommended that you use proper virtualization or sandboxing techniques to prevent any potential harm to your local systems. I am not responsible for any damage, data loss, or security issues that may arise if proper security measures are not followed. Always ensure your projects are contained and isolated to protect the integrity and safety of your machine.
This article was originally published on Medium. You can view it HERE .