triage-validation

> **⚠️ AUTHORIZED USE ONLY**

> This skill is for educational purposes or authorized security assessments only.

> You must have explicit, written permission from the system owner before using this tool.

> Misuse of this tool is illegal and strictly prohibited.

> **Mandatory confirmation gate**

> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:

> 1. Ask the user to state the exact target URL, IP, account, or resource.

> 2. Ask the user to confirm written authorization and the permitted scope.

> 3. Show the exact command(s) and explain their expected effect.

> 4. Wait for explicit confirmation in the current conversation.

>

> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.

# 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."

---

THE 7-QUESTION GATE

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

**If your bug maps to a listed exclusion → KILL IT.**

---

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)

**If out-of-scope → KILL IT.**

---

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:

1. Program's HackerOne/Bugcrowd disclosed reports: Ctrl+F endpoint name + bug class

2. GitHub issues on target repo: `is:issue label:security ENDPOINT_NAME`

3. Changelog/CHANGELOG.md — does it mention this behavior?

4. API docs / design docs — is it documented as intended?

**If acknowledged/design decision → KILL IT.**

---

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 fro