Why This Lab Matters

Most of my portfolio up to this point has been offensive. Finding vulnerabilities manually, exploiting them, and escalating privileges. This lab was different. It introduced me to vulnerability scanning from a professional standpoint, the way a security team at a company would approach assessing their own infrastructure. Nessus by Tenable is one of the most widely used vulnerability scanners in the industry, and getting hands-on time with it gave me a skill I can name specifically on a resume.

Setting Up Nessus

Nessus does not come pre-installed on Kali. The setup process involves downloading the Debian package from Tenable's website, installing it, starting the service, and then accessing the web interface https://localhost:8834.

sudo dpkg -i Nessus-*.deb
sudo systemctl start nessusd

The first time you run it, Nessus downloads and compiles thousands of plugins. This takes time, anywhere from 20 minutes to over an hour depending on your machine's resources. The plugins are what power Nessus's detection capabilities. Each plugin checks for a specific vulnerability, misconfiguration, or piece of information about the target.

I registered for Nessus Essentials Plus for Students, which gives a full year of access and the ability to scan up to 16 IP addresses. This is more than enough for lab work and personal practice.

Understanding Scan Types

One of the first things the room covers is the range of scan templates Nessus offers. Each is designed for a different purpose.

Host Discovery is the simplest scan. It just checks which hosts are alive on a network without doing any vulnerability checking. It is the equivalent of running a ping sweep.

Basic Network Scan is a general-purpose scan. It checks for open ports, identifies services, detects the operating system, and runs a broad set of vulnerability checks. This is the scan most people think of when they think of Nessus.

Credentialed Patch Audit goes deeper. It authenticates to the target using valid credentials and then checks what patches and updates are missing. An authenticated scan finds significantly more vulnerabilities than an unauthenticated one because it can inspect the system from the inside.

Web Application Tests focuses specifically on web vulnerabilities. It looks for things like SQL injection, cross-site scripting, exposed backup files, and authentication issues on web applications.

Understanding which scan to use in which situation is a key skill for anyone doing vulnerability assessments professionally.

Running the Basic Network Scan

Connecting to the TryHackMe VPN and pointing a Basic Network Scan at the target IP produced results within about 10 minutes. The scan returned 22 findings across different severity levels.

The one LOW severity finding was an ICMP Timestamp Request Remote Date Disclosure, which leaks the system's date and time to remote attackers. Not critical, but worth noting.

The INFO findings covered a range of system details including the OS fingerprint (Linux Kernel 2.6), open ports discovered by the Nessus SYN scanner, SSH version information, Apache HTTP Server version (2.4.41), and service detection results.

Each finding in Nessus has a Plugin ID. Plugin 10107 is the Service Detection plugin, which identifies the type and version of HTTP servers. Being able to look up plugin IDs is useful when writing reports or correlating findings across scans.

Running the Web Application Tests Scan

The Basic Network Scan gives you a network-level view. The Web Application Tests scan digs into the web server specifically and finds things the basic scan misses.

Running this scan against the same target surfaced two important findings that are exactly the kind of thing that shows up in real penetration test reports.

The first was a login page at login.php that transmits credentials in cleartext over HTTP. This means any attacker who can intercept the traffic between a user and the server can read usernames and passwords in plain text. In a real engagement this would be a medium to high severity finding depending on what the login page protects.

The second was a configuration backup file with a specific extension sitting on the web server in a publicly accessible location. Backup files left on web servers are a common finding. They often contain database credentials, API keys, or other sensitive configuration data that was never meant to be publicly accessible.

Reading Nessus Results

After completing both scans I had a much better understanding of how to read Nessus output. A few things stood out.

CVSS scores tell you the severity of a finding but context matters. A low CVSS score on an internal system might be more dangerous than a high score on an isolated test server, depending on what that system protects and who can reach it.

INFO findings are not vulnerabilities but they are valuable intelligence. Knowing the exact OS version, Apache version, and SSH version of a target tells an attacker exactly which public exploits to look for. Defenders need to understand this too.

The difference between authenticated and unauthenticated scans is significant. An unauthenticated scan sees what an outside attacker sees. An authenticated scan sees what an insider or someone with stolen credentials sees, which is almost always more.

What This Looks Like in a Real Engagement

A real vulnerability assessment follows a similar workflow to what this lab covers. Scan the target, review the findings by severity, verify the important ones manually, and produce a report with remediation recommendations. The login page transmitting credentials in cleartext would go in the report as a finding with a recommendation to enforce HTTPS. The exposed backup file would go in as a finding with a recommendation to remove it and audit the web server for other unintended files.

This is the workflow that security analysts and junior pentesters do in their day-to-day work. Getting comfortable with Nessus and understanding how to read its output is a practical skill that maps directly to job responsibilities.

Key Takeaways

Nessus scan types are not interchangeable. Running only a Basic Network Scan on a web application will miss web-specific vulnerabilities that the Web Application Tests scan would catch. Always match the scan type to what you are actually trying to assess.

Plugin IDs are worth knowing. When you see a finding in Nessus, the plugin ID tells you exactly what check fired. You can look up any plugin on Tenable's website to get the full details, references, and remediation guidance.

Cleartext credential transmission is still a common finding in real environments. Login pages over HTTP without HTTPS is a basic misconfiguration that Nessus catches reliably and that shows up frequently in real penetration test reports.

Exposed backup and config files on web servers are low-hanging fruit. Nessus finds them quickly, and they often contain the most sensitive information on the server.

Vulnerability scanning is the starting point, not the end point. Nessus tells you what might be wrong. The human analyst decides what actually is wrong, how serious it is in context, and what to do about it.

This lab is part of my ongoing security portfolio. You can find all my write-ups at github.com/barrytd/security-lab-portfolio.