Triage Validation

# TRIAGE & VALIDATION

One wrong answer = STOP this finding. Kill the finding. Move on to the next test class.

> Scope of "STOP" in this skill: This skill's gates kill INDIVIDUAL FINDINGS that fail validation. They do NOT authorize stopping the engagement. Killing a finding via the 7-Question Gate just means that finding doesn't get submitted — every other test class in the engagement is still pending. See redteam-mindset "DO NOT STOP primary directive" for the coverage-axis rule.

> "N/A hurts your validity ratio. Informative is neutral. Only submit what passes all 7 questions."

Ask IN ORDER. One wrong answer = STOP immediately.

Q1: Can an attacker use this RIGHT NOW, step by step?

Complete this template:

1. Setup:   I need [own account / another user's ID / no account] 2. Request: [exact HTTP method, URL, headers, body — copy-paste ready] 3. Result:  I can [read / modify / delete] [exact data shown in response] 4. Impact:  The real-world consequence is [account takeover / PII read / money stolen] 5. Cost:    Time: [X minutes], Capital: [$0 / $X subscription required]

If you CANNOT write step 2 as a real HTTP request → KILL IT.

Q2: Is the impact on the program's accepted impact list?

Go to the program page. Find "Vulnerability Types" or "Out of Scope."

Common tiers:

• Critical: Any-user ATO without interaction, RCE, SQLi with data exfil, admin auth bypass
• High: Mass PII exfil, privilege escalation, internal SSRF with data, stored XSS all users
• Medium: IDOR on specific user non-critical data, XSS on sensitive page requiring click
• Low: Non-sensitive info disclosure, clickjacking with PoC

Q3: Is the root cause in an in-scope asset?

Confirm:

• Vulnerable domain is on the in-scope list (not *.internal.target.com)
• It's a production asset (not staging/dev unless explicitly in scope)
• It's not a third-party service the company just uses (not Stripe, Salesforce, Google Auth)

Q4: Does it require privileged access that an attacker can't realistically get?

• "Admin can do X" = centralization risk = KILL IT (on 99% of programs)
• "Non-admin can do X that only admin should do" = valid
• "Requires physical access / MFA device" = usually invalid
• "Requires compromised victim account to work" = questionable, low severity at best

Q5: Is this already known or accepted behavior?

Search:

• Program's HackerOne/Bugcrowd disclosed reports: Ctrl+F endpoint name + bug class
• GitHub issues on target repo: is:issue label:security ENDPOINT_NAME
• Changelog/CHANGELOG.md — does it mention this behavior?
• API docs / design docs — is it documented as intended?

Q6: Can you prove impact beyond "technically possible"?

• XSS → show actual cookie theft or session hijack, not just alert(1) or alert(document.domain)
• SSRF → hit an internal endpoint that returns data, not just DNS ping
• SQLi → show actual data exfil from a real table, not just error message
• IDOR → show actual other-user's data in response, not just a 200 status code

Q7: Is this a known-invalid bug class?

Check the NEVER SUBMIT list below. If it's on this list without a chain → KILL IT.

Run in sequence. ALL 4 must PASS.

Gate 0: Reality Check (30 seconds)

[ ] Bug is REAL — confirmed with actual HTTP requests, not code reading alone
[ ] Bug is IN SCOPE — checked program scope page explicitly
[ ] Reproducible from scratch — can reproduce starting from fresh session
[ ] Evidence ready — screenshot, response body, or video

Gate 1: Impact Validation (2 minutes)

[ ] Can answer: "What can attacker DO that they couldn't before?"
[ ] Answer is more than "see non-sensitive data" (unless program pays for info disclosure)
[ ] Real victim: another user's data, company's data, financial loss
[ ] Not relying on victim doing something unlikely

Gate 2: Deduplication Check (5 minutes)

[ ] Searched HackerOne Hacktivity for this program + similar bug title/endpoint
[ ] Searched GitHub issues for target repo
[ ] Read most recent 5 disclosed reports for this program
[ ] Not a "known issue" in their changelog or public docs
[ ] Google: "TARGET_NAME ENDPOINT_NAME bug bounty"

Gate 3: Report Quality (10 minutes)

[ ] Title: [Bug Class] in [Endpoint] allows [actor] to [impact]
[ ] Steps to Reproduce: copy-pasteable HTTP request
[ ] Evidence: screenshot/video of actual impact (not just 200 status)
[ ] Severity: matches CVSS 3.1 score AND program's severity definitions
[ ] Remediation: 1-2 sentences of concrete fix
[ ] NEVER used "could potentially" or "may allow"

Submitting these destroys your validity ratio.

Missing CSP / HSTS / security headers
Missing SPF / DKIM / DMARC
GraphQL introspection alone (no auth bypass, no IDOR demonstrated)
Banner / version disclosure without working CVE exploit
Clickjacking on non-sensitive pages (no sensitive action PoC)
Tabnabbing
CSV injection (no actual code execution shown)
CORS wildcard (*) without credential exfil proof of concept
Logout CSRF
Self-XSS (only exploits own account)
Open redirect alone (no ATO or OAuth theft chain)
OAuth client_secret in mobile app (known, expected)
SSRF DNS callback only (no internal service access or data)
Host header injection alone (no password reset poisoning PoC)
Rate limit on non-critical forms (search, contact, login with Cloudflare)
Session not invalidated on logout
Concurrent sessions
Internal IP in error message
Mixed content
SSL weak ciphers
Missing HttpOnly / Secure cookie flags alone
Broken external links
Autocomplete on password fields
Pre-account takeover (usually — very specific conditions required)

Build the chain first, prove it works end to end, THEN report.

Common Score Examples

Metric Quick Guide

The goal is to QUICKLY disqualify bad leads so you hunt real bugs:

• 5-minute rule: If you can't fill in Q1's template in 5 minutes → move on
• Precondition count: More than 2 preconditions simultaneously required → kill it
• Impact test: "What does attacker walk away with?" — if nothing tangible → kill it
• Admin bypass: "Admin can do X" is NEVER a bug → kill it immediately
• Design doc test: If it's documented behavior → kill it immediately
• Rabbit hole signal: 30+ min on Q6 with no reproducible PoC → kill it

Before labelling any finding Critical or High anywhere in your notes or report — write out the answer to each of these as a one-liner. If you can't answer concretely, the severity is wrong.

• Have I validated the FULL chain to attacker-attainable impact, or only one primitive in the middle?

• What does the attacker walk away with, in one concrete sentence?

• Have I personally reproduced the full chain end-to-end at least twice?

• Is there an inheritance gate, signature check, audience check, or other validation step still gating the chain?

• Has the program rejected this severity class before?

Lesson from an authorized engagement: JWT alg:none was initially labelled Critical based on the signature-bypass primitive being confirmed at the audience-validation layer. Subsequent testing showed the issuer-trust check still rejected unsigned tokens — the full ATO chain did not complete. Finding had to be retracted. If the Pre-Severity Gate had been run on the original draft, Q1 would have killed the Critical label before submission.

When a previously-claimed finding fails reproduction — never silently drop it. Document the retraction in the report's appendix. This proves to the triager that you validate your own work, and it saves them from chasing a phantom you've already disproved.

Retraction entry template:

### Retracted: <finding name>
- **Original signal:** <one-line description of what looked like a bug> - **Disproving evidence:** <concrete reproduction-step + observation that disproves it> - **Why it looked like a bug:** <root cause of the false positive — e.g., natural marker collision, network jitter, status-code-only confidence> - **Retraction date:** <YYYY-MM-DD>

Concrete retractions from an authorized engagement — pattern reference:

• X-Forwarded-Proto reflection — looked like header reflection across 4 pages; was the literal word javascript in SP help-link hrefs. Cause: non-unique marker.
• Host header :80@evil bypass — 200 OK on a path that normally 403s; body byte-identical to baseline (8341 bytes). Cause: status-code-only confidence; ELB Host normalisation dropped the @evil portion.
• download.aspx file-existence oracle — looked like a file-existence differentiator across path types; was SP's file-extension blocklist (.ashx/.asmx/.svc/.config always blocked regardless of existence). Cause: confusing server-side policy with file state.
• Administrator timing leak — single-shot 1527 ms vs ~700 ms control on Authentication.asmx Login; n=80 interleaved reproduction collapsed every group to 685-716 ms. Cause: single-sample statistical claim.

• report-writing — When all 7 questions pass and the Pre-Severity Gate is clean. Workflow primitive: this skill is the gate that runs BEFORE report-writing; only findings that clear all 7Q + 4 pre-submission gates get the report-template handoff.
• bugcrowd-reporting — When a Bugcrowd VRT mapping is needed for an accepted finding. Workflow primitive: after this skill validates the finding, bugcrowd-reporting decides the VRT category and severity-request paragraph.
• evidence-hygiene — When the validated finding needs PoC evidence captured. Workflow primitive: this skill says "Q6 requires proof of impact"; evidence-hygiene provides the capture-and-redact protocol for that proof.
• security-arsenal — When checking the always-rejected / conditionally-valid tables. Workflow primitive: this skill's "Never Submit List" and security-arsenal's "Always Rejected" table are aligned; either entry-point lookup decides whether a primitive is reportable alone or only with a chain.
• bb-methodology — When Phase 5 (Validate & Report) starts. Workflow primitive: Phase 5's pre-report gate explicitly invokes /validate (this skill's 7Q gate) before any report is drafted.

> Engagement-derived additions to the vendored foundation. Wisdom from real > authorized engagements + Phase 2 verification across this repo's 31+ > skill-area live tests. The upstream methodology covers the WHAT; this > layer covers the WHEN-IT-ACTUALLY-WORKS and the FAILURE-MODES.

7-Question Gate at scale

The 7Q gate is the single highest-ROI artifact in this skill. Phase 2D's hardened-lab campaign verified it kills four distinct false-positive shapes:

• URL echo dressed as reflection — payload appears in the response body because the response IS the URL. Q1 (is this a real HTTP request that does something on the server) kills it.
• Word collision dressed as marker hit — the canary string XSS-test matched a CSS class name, not your injection. Marker Discipline + Q1 kill it.
• Server policy mistaken for state oracle — download.aspx?file=foo.config always returns "blocked" regardless of whether the file exists. Q6 (impact beyond technically possible) kills it: there's no oracle, just a deny-list.
• 200 OK without leak — status code differs from baseline 403; body is byte-identical. Body-Diff Rule + Q6 kill it.

Pre-Severity Gate before reporting Critical

A authorized SharePoint engagement nearly submitted a Critical when the chain didn't actually complete end-to-end — a primitive that read auth state was conflated with a primitive that mutated it. The Pre-Severity Gate (run all 7 questions specifically against the Critical claim, not the generic "is this a bug" claim) would have caught it.

Process: write your draft Critical title. Take each of the 7 questions and answer them with the Critical claim substituted for "the bug." If Q6 (impact beyond technically possible) returns "I have a primitive that should let me do X, but I haven't demonstrated X end-to-end on a test account," downgrade. Critical means impact-demonstrated, not impact-inferable.

Retraction discipline

If a finding stops reproducing 24h after submission — retract preemptively. Two reasons:

• Triagers retract for you with downgraded scoring. A self-retraction reads "the researcher validates their own work." A triager-retraction reads "the researcher submitted noise."
• Validation rate is platform-tracked. Self-retractions don't hit the same metric as triager-closed-as-N/A. Your reputation signal stays cleaner.

When the 7Q feels obstructive

The friction is the gate working. The half of findings that get killed by the 7Q are the half that would have come back as Informative or N/A. Take the friction. Your average payout per submission goes up when low-confidence findings stop diluting the funnel.

The exception: if the 7Q kills a finding but you still believe it, the answer is gather more evidence, not bypass the gate. The gate is a "do you have proof" check. Get proof, then re-run the gate.

Validation discipline rules cross-link

The 7 questions are the umbrella; the discipline rules from bb-methodology are the implementation: