In scanning & Enumeration you collect:
At the end of this step, you have something like:
80 → Apache 2.4.49
22 → OpenSSH 7.2This is just raw data / attack surface
The new phase: Vulnerability Analysis
Now you take the results from the previous phase and:
1. Match versions to known vulnerabilities
Example:
2. Check misconfigurations
3. Use scanners (THIS is where they come in)
Tools like:
Workflow Example
→ Finds:
→ Confirm vulnerability
'Vulnerability Assessment is a process that systematically identifies, analyzes, and evaluates security vulnerabilities in an organization's systems, applications, and networks.'
'Identifies, analyzes, and evaluates' – These are three distinct actions:
The Key Steps:
1. Asset Identification: Identifying systems, applications, and resources to assess.
Before you can assess vulnerabilities, you need to know what you have.
If you don't know what assets you have, you can't protect them. Asset identification is about creating and maintaining an inventory. This includes:
2. Vulnerability Scanning: Using automated tools to scan for known vulnerabilities.
You use software like Nessus, OpenVAS to automatically probe your systems and check for known weaknesses. The scanner has a database of thousands of known vulnerabilities each identified by a CVE, which stands for Common Vulnerabilities and Exposures.
A CVE is like a standardized ID for a specific vulnerability. For example, 'CVE-2021-44228' is the famous Log4Shell vulnerability. When a scanner finds that a system has an unpatched version of Log4j, it will report CVE-2021-44228.
The scanner works by:
3. Risk Evaluation: Prioritizing vulnerabilities based on potential impact and exploitability.
This is perhaps the most important step. A scanner might find hundreds or even thousands of vulnerabilities. You can't fix everything at once. You need to prioritize.
Risk evaluation considers:
Typically, vulnerabilities are scored using the CVSS system—Common Vulnerability Scoring System.
It gives a score from 0 to 10, with 10 being the most severe. A critical vulnerability (CVSS 9.0-10.0) that's easy to exploit and affects a critical system gets fixed immediately. A low-severity issue on a test server might wait until the next maintenance window.
Nessus: Widely used for comprehensive scanning and vulnerability detection.
Nessus, made by Tenable, is probably the most widely deployed vulnerability scanner in the world. It's been around for over 20 years and is considered an industry standard.
Key characteristics:
Use case: Nessus is great for organizations of all sizes. Small companies can use the free version, while large enterprises can deploy Nessus scanners across multiple locations and manage them centrally.
OpenVAS: Open-source solution for identifying known vulnerabilities in networks and systems.
OpenVAS stands for Open Vulnerability Assessment System. It's the open-source alternative to commercial scanners like Nessus.
Key characteristics:
The trade-off: While it's free, it typically requires more technical expertise to set up and maintain compared to commercial tools. The interface is less polished, and the reporting isn't as pretty. But for many organizations, it's more than sufficient.
Use case: OpenVAS is popular in academic environments, small businesses with Linux expertise, and as a secondary scanner for organizations that want to validate results from their primary commercial tool.
QualysGuard: Cloud-based tool offering continuous monitoring and in-depth vulnerability analysis.
Qualys takes a different approach. Instead of installing software on your own servers, Qualys is a cloud-based platform. You create an account, and their scanners (which can be virtual appliances or cloud-based) scan your infrastructure and send results to the Qualys cloud.
Key characteristics:
Use case: Qualys is popular in large enterprises, especially those with complex hybrid environments (on-premise and cloud). The continuous monitoring capability is valuable for organizations that need to maintain a strong security posture at all times.
Nuclei (Project Discovery): Fast, template-driven vulnerability scanner that uses community-maintained YAML templates to detect misconfigurations, exposures, and known CVEs through customizable probes.
Nuclei is a newer, different kind of scanner that's gained enormous popularity in the security community.
Key characteristics:
The difference: While Nessus and OpenVAS are comprehensive, general-purpose scanners, Nuclei is more like a precision tool. It excels at detecting specific misconfigurations and vulnerabilities quickly.
Use case: Security researchers, penetration testers, and DevSecOps teams love Nuclei. It's also great for continuous integration pipelines where you need fast, targeted scans.
There's no single 'best' tool. Many organizations use multiple tools. They might use Nessus for comprehensive quarterly scans, Qualys for continuous monitoring, and Nuclei for specific application security testing. The key is understanding what each tool does well and using them appropriately."
External Vulnerability Assessment
The scanner is placed outside the network, on the internet side. It's scanning from the perspective of an external attacker who doesn't have any inside access.
What does this simulate?
This simulates what an attacker on the internet can see and potentially exploit.
The scanner can only see what's exposed to the internet, typically your public-facing systems:
What can it find?
What can't it find?
Regulatory requirements: Many compliance frameworks (PCI DSS, for example) require external vulnerability scans at least quarterly.
Internal Vulnerability Assessment Setup
The scanner is now placed inside the corporate network. It has a much broader view.
What does this simulate?
This simulates two scenarios:
What can it find?
What's different about internal scanning?
Internal scanning typically reveals far more vulnerabilities than external scanning. Why? Because internal systems often:
Best practice: Do both. Scan externally to protect your perimeter. Scan internally to understand your true risk posture and prevent lateral movement.
1. Unauthenticated Assessment
'No credentials used → simulates outsider's view.'
The scanner connects to your systems over the network but doesn't log in. It doesn't have a username and password. It can only see what's exposed to the network.
What it can detect:
What it cannot detect:
Purpose: 'Identify attack surface & external exposure.' This tells you what an attacker can see without having any inside access. It's your perimeter view.
Use Case: 'External assessments (what an attacker sees).' When you're scanning from outside your network, you have no choice but to use unauthenticated scanning because you don't have credentials to internal systems.
The limitation: Unauthenticated scans can be misleading. For example, a system might have a vulnerable version of a service according to its banner, but that service might actually be patched and the banner just wasn't updated. Or conversely, a system might look patched based on its banner but actually have the vulnerable version. You don't get the full picture.
2. Authenticated Assessment
'Performed with valid credentials → simulates insider's view.'
Here, you provide the scanner with valid login credentials (username and password) for the systems being scanned. The scanner actually logs in to each system, just like a legitimate user would.
What it can detect:
Purpose: 'Reveal hidden vulnerabilities, misconfigurations, and patch gaps.' This gives you the complete picture of the system's security posture.
Use Case: 'Internal assessments (trusted user perspective).' When scanning inside your network, you should almost always use authenticated scanning. It gives you the most accurate and comprehensive results.
The practical impact on scan results
As an example, imagine scanning a Windows server:
Unauthenticated scan might see:
Authenticated scan would:
Best practice: Always use authenticated scanning where possible. For external systems where you can't provide credentials, unauthenticated is your only option. For internal scanning, configure your scanner with domain admin or local admin credentials to get the full picture.
Let's look at what actually happens under the hood when a vulnerability scanner runs.
Stage 1: Asset Discovery
'Asset discovery -> Project scanning (e.g. nmap)'
This is the reconnaissance phase. Before the scanner can find vulnerabilities, it needs to know what's out there. What systems are alive? What are their IP addresses? What ports are open?
How it works:
The scanner sends various probes to the target IP range to identify live hosts. Think of this as knocking on doors to see if anyone's home.
Common discovery techniques:
Nmap example:
A simple nmap command might look like:
nmap -sn 192.168.1.0/24This does a ping sweep of the entire 192.168.1.x network and tells you which IPs respond.
What asset discovery produces:
After this stage, the scanner has a list:
This becomes the target list for the next stage.
Why this matters:
Without accurate asset discovery, you'll miss systems. If a server doesn't respond to ping (maybe it's configured to block ICMP), but it has port 80 open (a web server), a good scanner will still find it through TCP SYN scans to common ports.
Stage 2: Fingerprinting & Enumeration
'Fingerprinting & Enumeration -> Service/technology profiling'
Now that we know which ports are open on which systems, we need to figure out what's actually running on those ports. Is that web server running Apache or Nginx? Is that database MySQL or PostgreSQL? What version?
This is like walking up to the door we found in stage 1 and figuring out who lives there.
How fingerprinting works:
The scanner connects to each open port and does two things:
What enumeration adds:
Enumeration goes beyond just identifying the service. It actively extracts information from the service:
Real-world examples:
Why fingerprinting accuracy matters:
If the scanner misidentifies a service, it will run the wrong vulnerability checks. For example:
This is why credentialed scanning is so powerful. When you provide credentials, the scanner doesn't have to guess from network responses. It can log in and ask the operating system directly: "What version of Apache is installed? What patches are applied?"
Stage 3: Attack Simulation
'Attack simulation (Not all VA scanners do this) -> Exploit checks with safe payloads'
This is the most sophisticated—and potentially dangerous—stage. The scanner actually attempts to simulate an attack to verify whether a vulnerability is real.
Important caveat: Not all vulnerability scanners do this. Basic vulnerability scanners stop at stage 2—they identify services and versions, then report potential vulnerabilities based on version numbers. If they see Apache 2.4.49, they'll report the path traversal vulnerability, even if that particular installation might have been patched in some non-standard way.
Attack simulation goes further. It actually tries to exploit the vulnerability, but with safe payloads.
What are safe payloads?
A payload is the code that actually triggers the vulnerability. 'Safe' means the payload is designed to:
For example, if testing for a SQL injection vulnerability:
If testing for a file inclusion vulnerability:
Why not all scanners do this:
The Complete Flow
Let's tie all three stages together with a concrete example:
Scenario: Scanning a target IP range that includes a web server.
Stage 1: Asset Discovery
Stage 2: Fingerprinting & Enumeration
Stage 3: Attack Simulation (if enabled)
How to Choose Your Scan Type
Now that Nessus is installed and initialized, we need to understand what kind of scans we can run. There are three main scan types, though Nessus actually has many more. These are the foundational ones.
0. ping only
1. Host Discovery
What it does: 'Which will test the reachability between the scanner and the Target IP's.'
Host discovery is the simplest type of scan. Its only goal is to determine which IP addresses in a given range have live, responsive systems.
How it works: The scanner sends various probes to determine if a host is alive:
If it gets any response, it marks the IP as 'alive.'
Use case: Before running a full vulnerability scan, you might run host discovery to identify which IPs in your target range are actually in use. This saves time—why scan 65,535 ports on an IP that doesn't respond to anything?
Limitation: Some systems are configured to ignore ping requests but still have services running. That's why host discovery uses multiple probe types.
2. Basic Network Scan
What it does: 'This will test all vulnerabilities that affect the target IP addresses, using a configurable set of plugins.'
This is your standard vulnerability scan. It does everything:
Configurable plugin set: You can customize which plugins run. For example:
Use case: This is your go-to scan type for regular vulnerability assessments. Run it weekly or monthly against your internal network.
3. Policy Compliance Auditing
What it does: 'Configuration review on the target based built in security auditing policy which include CIS, STIGS and more.'
This is a different kind of assessment. Instead of looking for vulnerabilities, it checks whether systems are configured according to security best practices or regulatory requirements.
CIS Benchmarks: CIS stands for Center for Internet Security. They publish detailed configuration guides for virtually every operating system, application, and device. A CIS benchmark might specify:
STIGS: STIG stands for Security Technical Implementation Guide. These are published by the U.S. Defense Information Systems Agency (DISA) and are even more stringent than CIS benchmarks. They're required for U.S. Department of Defense systems.
How it works: When you run a policy compliance scan with credentials, Nessus logs into the target system and checks hundreds of configuration settings against the chosen benchmark. It reports:
Use case: Organizations subject to regulations (like PCI DSS, HIPAA, or government contracts) often need to prove they're configured securely. Policy compliance scanning automates this audit process.
Other scan types (briefly):
Nessus has many specialized scan types:
For most purposes, Basic Network Scan with credentials enabled is what you'll use most often.
Now let's walk through the actual configuration of a Basic Network Scan in Nessus.
Step 1: Create a new scan
From the Nessus dashboard, click on 'Scans' in the top menu, then the 'New Scan' button (usually a blue button in the top right).
You'll see a gallery of scan templates. Click on 'Basic Network Scan.'
Step 2: Basic configuration
You'll see a form with several fields:
Step 3: Credentials (the key to authenticated scanning)
Click on the 'Credentials' tab. Here you can add credentials for different system types:
Windows credentials:
For Windows scanning, the account needs appropriate privileges. Typically, a domain administrator account or an account with local admin rights on target machines works best.
Linux/Unix credentials:
Database credentials:
Why provide credentials? As we discussed earlier, credentialed scans are dramatically more accurate and comprehensive. Nessus will use these credentials to log into each system and check patch levels, configurations, and local vulnerabilities directly.
Step 4: Save and launch
Click 'Save' to save your scan configuration. You'll be taken back to the Scans list, where you'll see your new scan. Click the play button (or 'Launch') to start it.
When you open your scan results, go to vulnerabilities tab
What it shows:
What you'll see in this list:
| Column | What It Means |
|---|---|
| Severity | Color-coded risk level (🔴 Critical, 🟠 High, 🟡 Medium, 🟢 Low, ℹ️ Info) |
| Plugin Name | The specific vulnerability name (e.g., "Apache 2.4.49 Multiple Vulnerabilities") |
| Plugin Family | Category (e.g., Web Servers, CGI Abuses, Database) |
| Hosts | How many targets have this issue |
| CVSS Score | Numerical risk rating (0-10, 10 being worst) |
When you click on any vulnerability, you get a DETAIL page with:
| Section | What It Tells You |
|---|---|
| Description | Plain English explanation of the vulnerability |
| Solution | How to fix it (update software, change config, etc.) |
| Risk Information | CVSS score, attack vector, complexity, etc. |
| Plugin Output | The evidence! What Nessus actually saw (very important) |
| References | Links to CVE databases, security advisories |
WHAT TO LOOK AT FIRST IN YOUR RESULTS