A company can spend millions on firewalls, antivirus software, and intrusion detection systems, yet still be completely compromised by a single forgotten open port on an old server. Vulnerability analysis is the disciplined process of finding those hidden weaknesses before a criminal does — and for the CEH (312-50) exam, it is the skill that separates an ethical hacker from someone who just runs tools without understanding what they reveal.
Jump to a section
A simple way to picture Vulnerability Analysis
Your neighbour’s house, late on a Saturday afternoon. You’ve agreed to check their property while they’re on holiday, but they’ve left you a simple task: walk around the outside and see if anything looks weak or broken. You start at the front gate. The latch is rusted and doesn’t catch properly — anyone could push it open. You move to the side door: the lock has been drilled out and replaced with a cheap padlock you could snap with a pair of pliers. Around the back, you find a basement window that’s been wedged open with a stick. Inside the shed, a ladder is leaning against the wall right next to an unlocked first-floor window. You are not a burglar. You are a home security inspector. Your job isn’t to break in — it’s to find every single way someone else could. You note each weakness on a clipboard, rank them by how easy they’d be to exploit (the rusty gate latch is trivial; the basement window requires a crowbar and some noise), and then write a report for your neighbour. That is vulnerability analysis: systematically inspecting a system (a house, a network, a web application) for flaws that an attacker could use, measuring how severe each flaw is, and presenting the findings so the owner can fix them before a real intruder shows up.
Vulnerability analysis is the systematic examination of a system or network to identify security weaknesses that could be exploited by an attacker. Think of it as a medical check-up for a computer: you run tests, look for symptoms of disease (vulnerabilities), and then decide which conditions need immediate treatment and which can be monitored.
To understand this properly, you need to know a few key terms. A vulnerability is a flaw or weakness in a system’s design, implementation, or operation that an attacker can use to cause harm. A threat is something (like a hacker, a virus, or a natural disaster) that could exploit that vulnerability. And a risk is the combination of a threat exploiting a vulnerability, multiplied by the potential impact. Vulnerability analysis focuses on the first part — finding the flaws.
The process has three main phases: vulnerability discovery, vulnerability verification, and vulnerability analysis.
In the discovery phase, you use automated tools such as Nessus, OpenVAS, or Qualys to scan systems for known weaknesses. These tools work by sending specially crafted packets (small units of data) to a target and observing how the target responds. For example, a vulnerability scanner might send a request that triggers a known bug in an old version of a web server. If the server responds in a way that matches the bug’s signature, the scanner flags it as a potential vulnerability.
But automated scans alone are not enough. Scanners produce many false positives — results that look like vulnerabilities but aren’t. That’s where manual verification comes in. An ethical hacker must examine each flagged item to confirm it is real. This might involve checking the version of a piece of software, reviewing configuration files, or even attempting a controlled exploit to prove the weakness exists.
Then comes the analysis phase. Here you take all confirmed vulnerabilities and prioritise them. Not all vulnerabilities are equally dangerous. The Common Vulnerability Scoring System (CVSS) is the standard way to rate severity, from 0.0 (no risk) to 10.0 (critical). A vulnerability on a public-facing web server that allows remote code execution (RCE) — meaning an attacker can run their own commands on that server — is a 9.0 or 10.0. A vulnerability that only allows a low-privileged local user to see some non-sensitive log files might be a 3.0. You must decide which to fix first based on impact, exploitability, and the value of the affected asset.
Vulnerability analysis is not a one-time event. It must be repeated regularly because new vulnerabilities are discovered every day. Software updates, called patches, often fix known vulnerabilities but can also introduce new ones. Network configurations change. Users make mistakes. So organisations run vulnerability scans weekly, monthly, or after any significant change to infrastructure.
There are two main types of scanning: authenticated and unauthenticated. Authenticated scanning uses valid login credentials (like a username and password) to access the system deeply, checking internal settings and configurations. Unauthenticated scanning looks only at what an outsider can see without logging in. Both are important because they simulate different attacker perspectives.
Vulnerability analysis also involves understanding the lifecycle of a vulnerability. A vulnerability is discovered by a researcher (or sometimes an attacker). It is reported to the vendor or disclosed publicly. A patch is developed and released. Systems are updated. But in the gap between discovery and patching — called the window of exposure — systems remain vulnerable. This is why rapid patching and proactive scanning are critical.
Finally, you need to know about the Common Vulnerabilities and Exposures (CVE) system. Each known vulnerability gets a unique CVE identifier (e.g., CVE-2024-1234) with a description and a CVSS score. Scanners and analysts use CVE IDs to track and communicate about specific vulnerabilities across different tools and teams.
Scope Definition
You must decide which systems, IP ranges, and applications are in scope for the assessment. You also agree on timing (to avoid disrupting business operations) and rules of engagement (whether you are allowed to attempt exploitative actions). This step prevents legal issues and system crashes.
Vulnerability Discovery (Scanning)
You use automated tools like Nessus, OpenVAS, or Qualys to scan the target systems. The scanner sends specially crafted packets and analyses responses to identify known vulnerabilities by matching them against a database of CVEs. This step produces a raw list of potential weaknesses.
Vulnerability Verification
You manually review each flagged item from the scan output. You check whether the vulnerability truly exists by examining software versions, configurations, or by attempting a controlled, non-destructive proof of concept. This step filters out false positives and confirms real weaknesses.
Vulnerability Analysis and Prioritisation
You take the list of confirmed vulnerabilities and assign each a priority based on its CVSS score, the value of the affected asset, and the business context. Critical and high-severity vulnerabilities that affect public-facing systems get top priority for remediation.
Reporting and Remediation
You write a clear report for stakeholders, listing each vulnerability, its risk level, and a recommended fix (e.g., patch, configuration change, or firewall rule). The IT team then applies the fixes. Finally, you rescan to confirm the vulnerabilities have been successfully addressed.
Ongoing Monitoring and Rescanning
Vulnerability analysis is not finished after one cycle. You schedule regular rescanning (weekly or monthly) and repeat the process whenever the environment changes, such as after new software is installed or network architecture is updated.
Imagine you are a junior security analyst at a mid-sized e-commerce company called ShopQuick. Your manager hands you the task of conducting a monthly vulnerability assessment of the company’s public-facing web application and internal network. You have never done this before, but you’ve studied for the CEH.
Your first step is to define the scope. You cannot scan everything — you might crash critical systems. So you agree with your manager which IP addresses and systems are in scope. The web server: 203.0.113.10. The database server: 203.0.113.20. The internal employee network: 10.0.0.0/24 (that means all addresses from 10.0.0.1 to 10.0.0.254). You also schedule the scan for 2 a.m. on Sunday, when traffic is lowest.
You launch your unauthenticated scan using Nessus — a popular vulnerability scanner. You configure it with the target IPs and select a “basic network scan” profile. The scan runs for about 45 minutes. When it finishes, Nessus shows 120 findings. That number is overwhelming, but you know it’s mostly noise.
You open the report. It lists items like:
TLS 1.0 Protocol Detection (medium severity) — old encryption protocol that’s weak but not immediately exploitable.
SSH Server CBC Mode Ciphers Enabled (low severity) — cryptographic weakness in how data is encrypted on the SSH service.
PHP Version 7.3.0 (critical severity) — known remote code execution vulnerability, CVE-2023-12345.
You immediately flag the PHP version issue as critical because it allows an attacker to take over the web server remotely. You verify it manually by checking the Apache response headers — yes, the server identifies itself as Apache/2.4.29 with PHP/7.3.0. This confirms the vulnerability. You also note the risk: the web server hosts the customer checkout page, which handles credit card data.
Next, you run an authenticated scan against the internal network. This requires a service account with read-only permissions on the Windows domain. The authenticated scan finds 45 more issues that the unauthenticated scan missed, like a misconfigured firewall rule that allows outbound traffic from the finance department’s subnet to the internet without inspection.
Now you produce your final report. You list the top 10 vulnerabilities by CVSS score, explain the business impact of each, and recommend a fix. For the PHP vulnerability, you write: “Upgrade PHP to version 8.0 or later immediately. This vulnerability allows arbitrary code execution on the web server. Estimated fix time: 30 minutes for the upgrade, plus testing.” You also recommend creating a patching policy that requires all critical patches to be applied within 48 hours.
You present this report to the IT manager and the security team. They decide to apply the critical patches that night. The next week, you re-scan to confirm the fixes work. This cycle — scan, analyse, report, patch, re-scan — is the daily reality of vulnerability analysis in a real company.
The CEH (312-50) exam tests vulnerability analysis in several specific ways. You need to know not just what it is, but exactly how the exam frames questions and what traps they set.
First, the exam asks about the phases of vulnerability analysis. There is a standard sequence: vulnerability discovery (scanning), vulnerability verification (manual confirmation), vulnerability analysis (prioritisation), and vulnerability remediation (fixing). They might present a jumbled list and ask you to order them correctly.
Second, you need to know the difference between vulnerability assessment and penetration testing. This is a classic exam trap. A vulnerability assessment finds and lists weaknesses; it does not actively exploit them. A penetration test actively attempts to exploit vulnerabilities to prove they are real and to see how far an attacker could go. The exam loves to ask which activity belongs to which type of test.
Third, the exam tests your knowledge of vulnerability classification systems, especially:
CVSS (Common Vulnerability Scoring System) — know its three metric groups: Base (inherent characteristics of the vulnerability, like attack vector and complexity), Temporal (factors that change over time, like exploit code maturity), and Environmental (how the vulnerability affects a specific organisation’s environment). You will not have to calculate CVSS scores, but you must recognise what each group measures.
CVE (Common Vulnerabilities and Exposures) — know that each vulnerability gets a unique identifier like CVE-2024-12345.
Fourth, expect questions about automated scanning tools. The exam mentions Nessus, OpenVAS, Qualys, Nexpose (now InsightVM), and Nikto (for web servers) by name. They ask which tool is best for a specific scenario: for example, “Which tool would you use for a credentialed scan of a Windows environment?” (Answer: Nessus or Qualys). They also ask about the difference between active and passive scanning: active scanning sends traffic to the target; passive scanning observes existing traffic without sending any.
Fifth, the exam tests your understanding of false positives and false negatives. A false positive is a scan result that flags a vulnerability that does not actually exist. A false negative is a real vulnerability that the scanner fails to detect. The exam asks which error is more dangerous (false negative, because it leaves a weakness undiscovered) and how to reduce them (manual verification reduces false positives; using multiple scanners reduces false negatives).
Sixth, there are questions about vulnerability management workflows. They describe a scenario where a company has a set of vulnerabilities and limited resources. You must prioritise correctly: fix critical CVSS 9+ vulnerabilities first, then high (7-8.9), then medium (4-6.9), then low. They might also test the concept of risk appetite — the amount of risk a company is willing to accept before requiring action.
Finally, watch for trick questions about the difference between vulnerability scanning and port scanning. Port scanning (using tools like Nmap) finds open ports and services. Vulnerability scanning goes a step further to check if the services on those ports have known weaknesses. The exam will sometimes describe a port scan and ask you to identify what it lacks.
Key definitions to memorise for the exam:
Exploit: a piece of code or technique that takes advantage of a vulnerability to cause unintended behaviour.
Zero-day vulnerability: a vulnerability that is unknown to the vendor and has no patch available.
CVE: a dictionary of publicly known vulnerabilities.
CVSS base score: a score from 0 to 10 that represents the severity of a vulnerability.
Vulnerability assessment vs. penetration testing: assessment is discovery; pen test is active exploitation.
False positive / false negative: know which is which and why manual verification matters.
Vulnerability analysis is a four-phase process: discovery, verification, analysis, and remediation.
A vulnerability scanner finds potential weaknesses; manual verification confirms which ones are real.
CVSS scores (0–10) help prioritise which vulnerabilities to fix first — critical (9+) before high (7–8.9).
A vulnerability assessment identifies weaknesses; a penetration test actively exploits them to prove impact.
False positives are scan results that claim a vulnerability exists when it does not; false negatives are real vulnerabilities the scanner missed — false negatives are more dangerous.
Authenticated scans with credentials reveal far more vulnerabilities than unauthenticated scans from outside the network.
The CVE system assigns a unique identifier (e.g., CVE-2024-12345) to every publicly known vulnerability.
Vulnerability analysis must be repeated regularly because new vulnerabilities are discovered and patched constantly.
These come up on the exam all the time. Here's how to tell them apart.
Vulnerability Assessment
Identifies and lists vulnerabilities without actively exploiting them
Produces a report of potential weaknesses with CVSS scores
Usually non-intrusive and safe for production systems
Penetration Testing
Actively exploits vulnerabilities to prove they exist and to measure impact
Simulates a real attacker's actions to see how deep they can go
Carries some risk of system disruption and requires careful rules of engagement
Authenticated Scan
Uses valid credentials to log in to the target system
Can inspect internal settings, patch levels, and configuration files deeply
Discovers vulnerabilities an insider could find, such as misconfigured local permissions
Unauthenticated Scan
Scans from outside the system without logging in
Only sees what an external attacker can detect, such as open ports and service banners
Misses vulnerabilities that require internal access to see (e.g., local file permissions)
False Positive
A scanner flags a vulnerability that does not actually exist
Wastes time because analysts must manually check and dismiss it
Can lead to unnecessary patching or configuration changes
False Negative
A scanner fails to detect a real vulnerability that is present
Leaves a real weakness undiscovered and exploitable by attackers
Considered more dangerous than false positives because it creates a blind spot
Active Scanning
Sends probe packets to the target and analyses responses
Can be detected by intrusion detection systems because it generates traffic
Provides more detailed information about the target's state
Passive Scanning
Listens to existing network traffic without sending any packets
Stealthy — it does not generate any traffic that can be detected
Only reveals what is visible in current traffic, which may miss idle or infrequently used services
Mistake
Vulnerability analysis is just running a scanner and looking at the results.
Correct
It includes planning, scoping, manual verification, prioritisation, and remediation — scanning is only one part of the process.
Beginners focus on the technical tool because it produces immediate output, but they overlook the analytical and managerial steps that give the results meaning.
Mistake
A vulnerability scan is the same as a penetration test.
Correct
A vulnerability scan identifies potential weaknesses; a penetration test actively exploits them to confirm real risk and demonstrate impact.
Both terms sound similar and some entry-level job postings use them interchangeably, but the CEH exam and security industry draw a sharp distinction.
Mistake
All vulnerabilities found by a scanner are real and dangerous.
Correct
Scanners produce many false positives (flagged items that are not actual vulnerabilities) and false negatives (missed vulnerabilities). Manual verification is essential.
When you first run a scanner, you see hundreds of results and assume they are all critical. It takes experience to learn to distrust raw scanner output and verify each finding.
Mistake
Vulnerability analysis is a one-time activity when setting up a network.
Correct
It must be performed continuously — weekly, monthly, or after any infrastructure change — because new vulnerabilities emerge daily and configurations drift over time.
Many beginners think security is something you 'do once and forget'. The reality of a constantly changing threat environment requires ongoing vigilance.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A vulnerability assessment identifies and lists weaknesses; a penetration test actively exploits those weaknesses to see how far an attacker could go. Think of the assessment as checking which doors are unlocked, and the pen test as walking through those doors to see what you can steal.
You do not need hands-on command-line proficiency, but you must know what Nessus is, what it does (vulnerability scanning), its basic features (authenticated vs unauthenticated scans), and how it produces CVSS-scored results. The exam tests conceptual understanding, not tool-specific syntax.
A false positive is a result that a scanner flags as a vulnerability when the system is actually not vulnerable. For example, the scanner might detect an old version of a library and assume it is vulnerable, but the system might have a custom patch that mitigates the issue. Manual verification eliminates false positives.
Best practice is to scan at least monthly, plus after any significant change to the environment (e.g., new systems, major software updates, or network reconfigurations). Critical systems may be scanned weekly. The exam will test that continuous scanning is more effective than one-time assessments.
CVSS stands for Common Vulnerability Scoring System. It provides a numerical score (0–10) for each vulnerability based on its severity. A score of 9.0 or higher is critical and should be fixed immediately. The exam tests your ability to recognise that CVSS helps prioritise which vulnerabilities to address first.
Yes, if the scan is too aggressive or targets unstable systems, it can cause crashes or denial of service. This is why scope definition and careful configuration are part of the vulnerability analysis workflow. The exam may ask you to identify when a scan should be stopped or to choose a less intrusive scan type.
You've finished Vulnerability Analysis. Continue through the 312-50 study guide to build a complete picture of the exam.
Done with this chapter?