What Is Exploit Validation?

A vulnerability scanner compares what it can see, such as a version string, a banner or a configuration, with a database of known issues. It answers "could this be vulnerable?" and it answers it for every host at once. That is useful and cheap, but it produces long lists: a version match does not show that the vulnerable code is reachable, that the right conditions are met, or that a control in front of it does not block the attack.

Scores then try to rank the list. CVSS describes how severe a vulnerability is in general. EPSS estimates how likely it is to be exploited somewhere in the next 30 days. The CISA KEV catalog lists vulnerabilities with evidence of exploitation in the wild. None of them looks at your network.

Exploit validation does. It takes a finding and tries it, in a controlled way, against the real target, so the answer reflects your versions, your configuration and your controls. Gartner groups the tools that do this continuously under Adversarial Exposure Validation (AEV).

• 1. Version or banner match

  The software and version look vulnerable. This is what a scanner reports. It is a hypothesis, and many such findings are not exploitable in practice.

• 2. Precondition confirmed

  A safe check shows that the vulnerable feature is enabled or the endpoint responds as the vulnerable version would. Stronger, but still not proof that an attacker gets anything.

• 3. Exploitation with evidence

  The exploit was run, it worked, and the record shows what it reached: a command executed, a file read, a session obtained, a credential captured. This is the only level that counts as proof.

When a vendor says "validated", ask which of the three levels it means. Simulating an attack, replaying a scenario or matching a signature is not the same as exploiting the target, and the difference matters when you decide what to fix first.

1. 1Start from findings and exposure. Scanner results, external attack surface, KEV-listed CVEs and the assets that matter most.
2. 2Set the rules. Scope that the platform enforces, testing windows, which techniques need human approval and who can stop the test.
3. 3Attempt the exploit. Pick or build an exploit for the specific target and run it from a realistic position: from the internet (black box) or from an ordinary user account (gray box).
4. 4Judge the result against the output. Decide success from what actually happened on the target, not from whether a script ran. A script that exits with an error has not proven anything.
5. 5Record the evidence. Technique, request, response, post-access result and timestamps, in a tamper-evident log.
6. 6Chain where possible. One proven foothold often leads to the next host. The path matters more than any single finding.
7. 7Re-test after the fix. Replay the same exploit. If it no longer works, the finding is closed with evidence.

Evidence is what makes a validated finding usable by the team that fixes it and by the auditor who checks it later. For each proven finding you should get:

• The exact technique and the request or command that was sent.
• The target's response, enough to show the exploit worked and was not a false match.
• What was reached after access: the command output, the file, the session or the privilege obtained.
• Timestamps and the identity of whoever ran or approved it, including when a person rather than the platform made the call.
• A record that cannot be edited afterwards. Signed, chained entries let anyone check that the report matches what happened.

Evidence can contain sensitive data, such as captured credentials or records. Ask where it is stored and who can see it. Storing hashes of raw output instead of the output itself is one way to keep proof without copying the data.

• In CTEM it is the validation stage: after scoping, discovery and prioritisation, before mobilisation.
• In patching programmes it turns a KEV or emergency patch list into an order of work, and proves which systems are still exposed while the fix is pending. See the KEV emergency patch window playbook and CISA BOD 26-04.
• In penetration testing it is the core of the job. An automated penetration test that only lists scanner results has skipped it.
• In continuous automated red teaming it runs on a schedule, so a configuration change that reopens an attack path shows up within days rather than at the next annual test.

• Safety. Exploiting a production system can disrupt it. Disruptive techniques should wait for a human approval, fragile systems such as OT or legacy servers need tighter limits, and someone must be able to stop everything at once.
• Coverage. Validation proves what was tested. A finding that was not attempted is unproven, not safe, and should stay open.
• Position. "Not exploitable from the internet" is not "not exploitable". Test again from an internal, assumed-breach position.
• Time. A finding that was not exploitable yesterday can become exploitable after a change or a new public exploit. Validation has to be repeated.
• People still matter. Business-logic flaws in custom applications, social engineering and regulator-led tests such as DORA TLPT stay with human teams.

How does exploit validation compare to CVE-based risk scoring? Scoring estimates how dangerous a CVE is in general; validation tests whether it can be exploited on your host, with your controls in place. Use scores to decide what to test first and validation to decide what to fix first.

How do I tell whether a vendor's validation is real exploitation or simulation? Ask for the evidence of three findings: the request sent, the target's response and what was obtained after access. Then try to reproduce them with your own team. Simulated or replayed scenarios cannot show post-access results on your systems. The pilot scorecard gives a structured way to check.

Is exploit validation safe on production? It can be, with a platform-enforced scope, human approval for disruptive actions and an emergency stop. Start on systems where a short outage would be tolerable and widen the scope as confidence grows.

Is exploit validation the same as a penetration test? It is the central step of one. A penetration test adds discovery, chaining, lateral movement and a report. Continuous validation tools run that step far more often than a yearly test.

What is proof-based scanning? A scanner that confirms some findings by safely triggering them, for example by reading back a harmless marker. It sits at the second or third level of proof for those checks, but it does not chain findings into attack paths.

How does Zero Hunt handle exploit validation? Zero Hunt is an autonomous AI red team that runs on an on-premise appliance with its own models, in black-box and gray-box mode. A finding the engine has not exploited is marked as unproven and its severity is capped until there is proof. An operator can choose to run the exploit for a single finding: that requires a written, named consent, re-checks the current scope, locks the host and writes a signed record. The engine proposes a verdict from the real output, and the operator has the final word. Evidence is Ed25519-signed and hash-chained. Zero Hunt publishes no benchmark numbers yet; its evaluation methodology is in preparation.