Evaluating Exploit Evidence

Summary

Exploit evidence ranges from proof of concept and public code to credible reports of observed exploitation. It must be read with source date, prerequisites, affected versions, authentication and privilege requirements, user interaction, configuration, attack-path reachability, local applicability, local exposure, and telemetry gaps.

Learning objectives

• Separate vulnerability existence, exploitability, exploit availability, observed exploitation, scanning, and local compromise.
• Classify evidence without turning KEV, EPSS, or public code into proof of a local incident.
• Record confidence, freshness, uncertainty, and the next validation question.

Why this matters

A proof of concept does not prove local compromise. Exploit code availability does not prove successful exploitation. Scanning activity does not prove exploitation. KEV inclusion does not prove the environment was attacked, and EPSS does not prove exploitation. Absence from KEV does not make a vulnerability safe.

Guided workflow

1. Confirm the exact vulnerability, affected versions, and local applicability.
2. Identify the evidence claim, original source, publication and observation dates, and evidence type.
3. Review prerequisites, reproducibility, corroboration, vendor and government context, local exposure, telemetry, confidence, uncertainty, and operational implication.

Fictional worked example

A fictional vendor says exploitation is under investigation; a government catalog lists known exploitation; a researcher publishes a limited proof of concept; a provider reports attempts; local logs show scanning but no confirmed execution. These sources support different claims. A public-facing instance needs exposure review; an internal-only instance needs an attack-path review. Neither log set proves compromise without execution evidence.

Decision exercise

Classify fictional statements as exploit availability, observed exploitation, scanning, local compromise evidence, unsupported claim, or insufficient evidence. Name the source, freshness, prerequisite, and next local check.

Knowledge checks

1. Does a proof of concept prove compromise? No; it can show feasibility without local execution evidence.
2. Does scanning equal exploitation? No; scanning may be probing without successful execution.
3. What does KEV indicate? Recognized known exploitation somewhere, not local attack or compromise.
4. What does EPSS prove? Nothing about an individual environment; it is a modeled signal.
5. Why review prerequisites? They determine whether an exploit claim maps to the local configuration and attack path.

Answer explanations

Useful answers preserve provenance, limits, and local gaps. They do not prove mastery, certification, or operational authority.

Common misconceptions

Public code proves exploitation; a vendor phrase is timeless; KEV proves compromise; no KEV means safe; or a scanner event is an incident.

Practical takeaway

Write an evidence note: claim, source, date, type, prerequisites, corroboration, local applicability, exposure, telemetry, confidence, uncertainty, and next owner question.

Related content

Exploit Evidence Validation, Investigation Evidence Quality, IOC Extractor, Incident Timeline Reconstruction, Curated CVEs, and CISA KEV.

Limitations

This Lesson cannot establish local exploitation, compromise, or attribution. Missing telemetry remains an information gap.

Last reviewed: Unknown. Recheck current sources and local evidence before acting.