3.1 Vulnerability Analysis Concepts

Why Vulnerability Analysis Matters on the CEH

Vulnerability analysis is the bridge between reconnaissance and exploitation. The Certified Ethical Hacker (CEH) blueprint groups it under System Hacking Phases and Attack Techniques (about 15% of the exam). You will be asked to interpret scores, classify weaknesses, and recommend a defensible remediation order — not to run exploits. Treat this section as the analyst's vocabulary you must speak fluently.

Vulnerability vs. Threat vs. Risk

These three terms are tested constantly, and the exam punishes loose usage:

• A vulnerability is a weakness or flaw in a system, configuration, process, or person that could be exploited (for example, a missing patch or a default credential).
• A threat is any circumstance or actor with the potential to cause harm by exploiting a vulnerability (for example, a ransomware crew or a malicious insider).
• Risk is the likelihood that a threat exploits a vulnerability multiplied by the resulting business impact. A vulnerability with no reachable threat path is low risk even if the flaw is severe.

A fourth term, exposure, describes the actual state of being susceptible — an asset that is reachable and unpatched is exposed, not merely vulnerable in theory.

Classifying Vulnerabilities

The CEH expects you to recognize broad vulnerability categories rather than memorize every flaw:

• Misconfiguration — default accounts, open shares, verbose error pages, weak permissions.
• Missing patches / default installs — unpatched operating systems and services.
• Design or logic flaws — flawed authentication or trust assumptions baked into the architecture.
• Application coding flaws — injection, memory-safety issues, broken input validation.
• Default and weak credentials — vendor defaults left unchanged.
• Operating-system / kernel flaws — privilege boundary weaknesses.
• Human / process weaknesses — the soft target that drives social engineering.

Vulnerabilities are also catalogued by Common Weakness Enumeration (CWE), a community taxonomy of weakness types (e.g., CWE-79 cross-site scripting). CWE describes the class; CVE names the specific instance in a specific product.

CVSS: Scoring Severity

The Common Vulnerability Scoring System (CVSS) is the industry-standard way to express how severe a vulnerability is. The widely deployed CVSS v3.1 produces a numeric score from 0.0 to 10.0 built from three metric groups:

• Base — intrinsic characteristics that do not change over time: attack vector, attack complexity, privileges required, user interaction, scope, and the confidentiality/integrity/availability impacts.
• Temporal — characteristics that change over time, such as exploit code maturity and remediation level.
• Environmental — how the vulnerability matters in your environment, allowing you to re-weight impact for your asset criticality.

For the exam, memorize the qualitative severity bands that map to the base score:

The newer CVSS v4.0 (published by FIRST) keeps the same 0.0-10.0 scale and the same qualitative bands, but reorganizes the metrics into four groups — Base, Threat, Environmental, and Supplemental — renaming the old Temporal group to Threat and adding Supplemental metrics that give context without changing the score. It also splits attack complexity into Attack Complexity and Attack Requirements. Score alone is not a remediation order — combine it with exploitability, exposure, and asset value.

CVE and NVD

• CVE (Common Vulnerabilities and Exposures) is a dictionary of unique identifiers in the form CVE-YYYY-NNNN+ assigned by CVE Numbering Authorities (CNAs). A CVE entry names one specific flaw in one product so everyone references it the same way.
• The National Vulnerability Database (NVD), run by the U.S. National Institute of Standards and Technology (NIST), consumes CVE records and enriches them with CVSS base scores, CWE weakness mappings, and affected-product (CPE) data.

Mnemonic for the exam: CVE names it, CWE classifies the weakness type, CVSS scores it, NVD enriches and indexes it.

The Vulnerability Management Lifecycle

Vulnerability management is a continuous program, not a one-off scan. The CEH presents it as a repeating loop:

1. Identify (Discover) — inventory assets and run scans to find weaknesses. You cannot protect assets you do not know exist, so asset discovery comes first.
2. Assess and Prioritize — validate findings, remove false positives, and rank by CVSS, exploitability, exposure, and business criticality.
3. Remediate — patch, reconfigure, apply compensating controls, or formally accept the risk.
4. Verify (Rescan) — confirm the fix actually closed the finding and did not regress.
5. Report and Monitor — document, trend over time, and feed results back into the next cycle.

A related but distinct activity is the vulnerability assessment itself: identifying and cataloging weaknesses without exploiting them. Penetration testing goes further by safely demonstrating real exploitability and business impact. Confusing these two is a classic CEH trap.

Scanners and Their Limits

The exam names specific tools. Know what each is:

Scanner behaviors to match to a goal:

• Network / infrastructure scanners assess hosts, ports, services, and missing patches across the network.
• Host-based / agent scanners run on the endpoint and see local configuration the network cannot.
• Active scanners send probes (more data, more noise, possible disruption); passive scanners observe traffic only.
• Authenticated (credentialed) scans log in (SSH keys on Linux, WMI/admin on Windows) and see far more than unauthenticated scans, which only see the external surface.

Limitations to remember: every scanner produces false positives (reported but not real) and false negatives (real but missed); scanners can disrupt fragile systems; coverage depends on the plugin/signature feed being current; and a scanner finds known issues only — it never replaces skilled human validation.