Scope Triage

TL;DR

• 目的：Perform recon scope triage assessment during authorized security testing. Use this skill when indicators of the vulnerability class are present in the
• 适用：通用
• 输入：目标信息
• 输出：执行结果 + 证据
• 红线：仅限授权范围内；扫描限速 -c 10 -rl 10；所有动作记 oplog
• 关联：上游：003-src-session-start → 下游：003-src-session-start（按需调用）

Web "Critical" triage — the soft-404 control

Automated .env / .git / actuator / admin-panel "Criticals" are overwhelmingly soft-404s: SPA/framework catch-alls returning HTTP 200 (or 403) for every path. Verify EACH before believing it:

# the "finding"
curl -s -o /tmp/a -w "%{http_code} %{size_download}\n" https://host.target.com/.env
# a junk control on the same host
curl -s -o /tmp/b -w "%{http_code} %{size_download}\n" https://host.target.com/zzz-nonsense-$RANDOM
# identical byte length / body  →  FALSE POSITIVE (catch-all), discard
cmp -s /tmp/a /tmp/b && echo "SOFT-404 false positive" || echo "differs — investigate"

Real exposures have a content-type + signature that differs from the catch-all (.git/config starts [core]; .env has KEY=value; phpinfo has the XHTML-transitional doctype + PHP Version). A physical .php/phpinfo.php that returns a bigger/different body than the junk control is the real-vs-soft-404 tell.

The triage workflow

1. Confirm the canonical owned-domain set first (the SOW/program domain + its verified subdomains + the verified Entra/Okta/Google tenant brand name). This is your ownership anchor.
2. For each asset class, apply the verify-by column above. No signal → quarantine, don't test.
3. Re-baseline the severity counts against only-owned assets. Report the delta — "N Criticals → M after ownership + soft-404 triage" is itself a finding about the ASM program.
4. Quarantine collisions explicitly (a loot/quarantined_<source>.txt) so it's auditable that you saw them and chose not to target them.
5. Surface the meta-finding: if the supplied ASM/recon feed is mostly false-positive, that misallocates the owner's remediation budget and buries real risk — write it up (Medium/Strategic).

Anti-patterns

• Trusting the tool's "owned" label. Tools keyword-match; they don't prove ownership. Verify.
• Targeting a same-named third party because it was "in the report." Out of scope + real harm. A combo line user@<word>company.com is a different company's employee.
• Reporting soft-404s as exposures. Always run the junk-path control.
• Counting typosquats / missing-headers / brand-collision repos as offensive findings. They're defensive/hygiene/noise — they pad the report and erode credibility.
• Skipping triage "to save time." Untriaged, you spend the whole engagement on other people's assets and find nothing real.

Why this matters (calibration)

For a target whose brand is a common word, expect the bulk of automated "owned" assets to be collisions:

• Repos that are unrelated open-source projects (ad-block lists, scrapers, student projects, a different company's SDK) merely containing the word.
• Mobile apps published by entirely different companies that share the name — banks, credit unions, dating apps, dispensaries, home-care services are all real-world collision categories. (Good ASM tooling will tell you it accepted zero as owned.)
• Cloud buckets in the global namespace holding some unrelated org's content (other-language documents, demo/sample data, another industry's files).
• Breach combos full of emails from sibling-named-but-different companies (<word>group.com, <region><word>.com).

On a real engagement against a dictionary-word brand, after clearing this noise the only genuinely-owned high-severity finding was discoverable solely by manual tradecraft (a JS-bundle → API discovery, see hunt-spa-api) — it was nowhere in the hundreds of scanner "Criticals." Triage-first is what made the engagement productive instead of a goose chase.

Workflow

1. Seed input — Root domain, company name, or ASN as starting point
2. Passive collection — crt.sh, shodan, censys, theHarvester (no target touch)
3. Active enumeration — subfinder with public resolvers (-rate-limit 20)
4. Validation — Resolve and probe live hosts (httpx)
5. Fingerprint — Identify technology stack (nmap, wappalyzer)
6. Reporting — Aggregate findings into recon report

Related Skills & Chains

• triage-validation — asset-ownership triage (this skill) precedes finding-validity triage (the 7-Question Gate). Ownership first, then validity.
• redteam-mindset — "aggressive default" means probe every owned live surface; this skill defines which surfaces are owned so persistence isn't wasted on collisions.
• hunt-spa-api — once an API host passes ownership triage, this is how you test it.
• offensive-osint / osint-methodology — feed ownership anchors (verified domains, tenant brand, dev accounts) from OSINT into this triage.

When to Use

• Target presents indicators of the vulnerability class this skill covers
• Fingerprint or recon indicates the relevant technology stack is in use
• Authorized testing scope covers the target endpoint or component
• Findings need to be validated through this skill's methodology

When NOT to Use

• Target is clearly outside this skill's scope (refer to related skills)
• No authorization for testing
• Need a different category of testing (use related skills)