oasm-platform/open-asm/exploit-verification

Exploit verification & evidence

A finding is worth reporting only when the evidence shows the condition that makes it exploitable. This skill is about proving safely and honestly: the verdict matters more than the finding count.

When to use

• You have a candidate and must decide whether it is real before reporting it.
• A scanner or another agent flagged something and you must separate a true positive from noise.
• You are retesting an existing finding after a fix.

1. State the hypothesis

Write down three things before you send anything:

• the exact condition that makes this exploitable ("the q parameter is concatenated into the SQL string unescaped");
• the observation that proves it true (a boolean pair that flips the result set, a 5-second delay on the time-based variant only);
• the observation that proves it false (both payloads behave like the benign control).

If you cannot name the false-observation, you cannot verify anything — you have a hunch.

2. Choose the least intrusive proof

Prefer, in this order: a single crafted request; a benign unique marker; a boolean or timing differential; an out-of-band callback; a state change that is trivially reversible. Never move up this list for convenience.

Reproduce through the same route that produced the original claim (same endpoint, same identity, same tool), so the comparison is like-for-like.

3. Always build the negative control

Send the payload that should trigger the condition and a benign variant that should behave differently. If both behave the same, what you saw was not the vulnerability. The control is what turns an observation into a proof:

• injection: 1' AND 1=1 vs 1' AND 1=2 — different results mean the query is being shaped by input;
• reflection: your marker next to a value that should not reflect;
• access control: the victim's object as the attacker, then the same object as its owner;
• SSRF: the callback that arrives, then the same request with a dead host that produces no callback;
• auth: the privileged request with a valid token, then the same one without it.

4. Read the real output

Judge from what came back, not from what you expected. A tool error, a proxy failure, a rate-limit page or a WAF block page is not target behaviour and not evidence — it is an inconclusive result. Read long output with read_tool_output and a pattern.

5. Close the candidate — exactly one state

• Confirmed: a working proof, or a complete reachable trace from source to sink to impact.
• Ruled out: you can name the specific control, at the point it runs, on every attacker-reachable path before the sink.
• Open: plausible, unconfirmed, and no such control was named.

"I moved on" is not a close. Missing information is NOT proof of safety — a service you could not start, a caller you could not find, a hypothesis you could not execute are all open, never "clean".

6. Counterevidence before you report

Argue the strongest case against the finding and record it:

• What control should have blocked this, and did you test that it did not?
• Could the difference be your own test setup — a cached response, a mixed-up session, a state you changed yourself?
• Is the data actually sensitive, or is it public by design?
• Would this survive first contact with the asset owner's triage?

Set confidence honestly: a static trace you never executed is at best medium.

Safe-proof rules

• Minimal impact: demonstrate the flaw without damaging, reaching real user data at scale, or degrading the service.
• No real exploitation: show that injection changes the query — do not exfiltrate the database. Show one unauthorized object is reachable — do not harvest records. Show a secret is exposed — do not reuse it.
• Reproducible: capture the exact request (method, URL, headers, body), the decisive response lines next to the baseline, and the command or run id that produced them. Mask secrets and personal data.
• Honest: if the evidence is weak, say open. Never upgrade a guess to confirmed, and never invent a CVSS score, a CVE or a line of output.

Severity follows the proof

Score only what you demonstrated. Reachability, a missing header, a version banner, a public identifier and a scanner label are observations, not impact. A chain is reported at the severity of what it demonstrably reaches, with the chain spelled out.

Output

A verdict block: the hypothesis; the verdict (Confirmed / Ruled out / Open) with the reason; the reproducible evidence (request + baseline and exploit response lines, secrets masked); the counterevidence you considered; and, if confirmed, one line on the realistic impact and what would change the severity.