跳到正文
cccskills
免费在 GitHub 公开

recon-scope-triage

Review security discovery results to distinguish a target organization’s assets from unrelated assets sharing its name. Check ownership evidence, identify misleading web responses, quarantine uncertain entries, and recalculate severity counts before proceeding with security testing.

中文简介正在准备中。当前显示英语简介。

原文查看原文说明

Triage ASM/recon output for ownership before testing — separate the target's real assets from namespace-collision noise. Automated recon keyword-matches on the brand name, so for any target whose name is a common/dictionary word, the output is dominated by assets belonging to UNRELATED same-named companies (repos, cloud buckets, mobile apps, breach corpora, typosquats). Built from an authorized engagement where an ASM report's "Criticals" were overwhelmingly false positives and the combo/repos/mobile/bucket lists were polluted with unrelated same-named orgs. Use at the START of any engagement, immediately on receiving any ASM/recon/OSINT dataset, BEFORE testing anything.

查看安装方法

适用场景

  • Check asset ownership before security testing
  • Separate unrelated organizations with matching names
  • Validate unusually high critical finding counts
  • Keep an auditable record of quarantined assets

包含的文件(1)

  • SKILL.md7.3 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

When to use this skill

Trigger when:

  • The target brand is a common/dictionary word or shared term (e.g. apex, summit, vertex, nova, core, orbit, pulse, unity…)
  • You receive an ASM report, recon export, breach combo, repo list, bucket list, or mobile-app list to act on
  • A "Critical" count looks implausibly high (hundreds) for the org's size
  • Any asset's ownership is asserted by the tool but not proven

The two failure modes this skill prevents:

  1. Wasting the engagement testing/triaging assets that aren't the target's.
  2. Attacking an innocent third party that merely shares the name — out of scope, and real harm.

Rule: ownership is guilty-until-proven. An asset is the target's only when a concrete ownership signal ties it to the target — never because a scanner's keyword matched.


The collision sources (where keyword-matching lies)

Recon sourceHow it collidesVerify ownership by
GitHub reposSearch matched the brand word in repo name / topic / a stringRepo owner is the org's GH org; commits from org emails; code references the org's real domains/infra. A repo named <word>-backend by a random user = noise.
Cloud buckets (S3/GCS)Bucket names are a global namespace; <word>-static, <word>-data, <word>-public exist for someoneBucket content references the target; bucket name correlates with a confirmed target subdomain (x.target.com ↔ x-public) AND content matches; ACL/owner metadata. Generic content (other-language, other-industry) = not theirs.
Mobile appsStore search matched the brand word in app name / packagePublisher account = the org; package reverse-DNS = an owned domain (com.<owneddomain>.app); dev cert; app calls owned API hosts. Mature ASM tools emit an "apps_accepted=0" / ownership-confidence field — read it.
Breach corpora / combosEmail local-or-domain contains the brand wordExact owned-domain match only (@target.com), not @<word>group.com / @something<word>.com. A different domain that contains the word is a different org.
TyposquatsGenerated permutations of the nameThese are defensive/brand-protection findings, not offensive scope — note and move on.
Stack/forum/paste hitsBrand word in bodyBody references the target's real domain/subdomain/employee/secret. Ownership-confidence < threshold = drop.

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.


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.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Inspect Android apps for embedded credentials, internal API addresses, and components exposed to other apps. The skill guides APK acquisition, code inspection, and runtime traffic analysis to support a mobile security assessment.

中文简介正在准备中。当前显示英语简介。

  • Inventory Android apps included in a security assessment
  • Check APKs for embedded credentials and internal API addresses
  • Review components that other apps can invoke
elementalsouls/Claude-BugHunter52462026年10月22日 更新

Guide bug bounty work from asset discovery to validation and reporting, while resolving local locations of security tools, wordlists, and cloned projects. It covers web and AI security testing with an emphasis on demonstrated impact.

中文简介正在准备中。当前显示英语简介。

  • Locate installed security tools and wordlists
  • Plan reconnaissance within a program's scope
  • Investigate related weaknesses and their combined impact
elementalsouls/Claude-BugHunter52462026年10月22日 更新

Organize a bug bounty investigation from reconnaissance through reporting. The skill helps choose a focused objective, identify the current phase, select relevant techniques and tools, and distinguish reproducible security impact from misleading test results.

中文简介正在准备中。当前显示英语简介。

  • Setting objectives at the start of an investigation
  • Choosing the next step when testing stalls
  • Replanning after switching targets
elementalsouls/Claude-BugHunter52462026年10月22日 更新

Guide bug bounty work from checking authorized scope and discovering assets to testing web and AI features. Validate practical impact, investigate related weaknesses, and organize reproducible evidence into a vulnerability report.

中文简介正在准备中。当前显示英语简介。

  • Planning research for a new bug bounty target
  • Reviewing source code for security weaknesses
  • Testing chatbot and AI feature security
elementalsouls/Claude-BugHunter52462026年10月22日 更新

Prepare Bugcrowd submissions with accurate vulnerability categories, evidence-based severity requests, and explanations of program scope. Structure references between related reports, document QA testing conditions, and draft responses when a finding is downgraded or considered out of scope.

中文简介正在准备中。当前显示英语简介。

  • Choose a suitable Bugcrowd vulnerability category
  • Explain a severity request using demonstrated impact
  • Respond to out-of-scope decisions
elementalsouls/Claude-BugHunter52462026年10月22日 更新

Assess what discovered cloud credentials allow across AWS, Azure, GCP, and Kubernetes. The skill guides identity checks, permission review, and paths to higher privileges, then helps document impact, activity, and cleanup within the engagement's agreed scope.

中文简介正在准备中。当前显示英语简介。

  • Assess permissions granted by discovered cloud credentials
  • Review role trust and access across cloud accounts
  • Check permissions assigned to anonymous Cognito identities
elementalsouls/Claude-BugHunter52462026年10月22日 更新

查看 elementalsouls 的全部技能

报告此技能的问题