OSINT 方法论

把授权范围内的外部侦察做成可审计的工程

做外部红队或 ASM 项目时，真正的难题往往不是「找不到资产」，而是信息越积越多之后回答不了三个问题：这条结论有多可信、证据能不能复现、操作有没有越过边界。截图、DNS 记录和 HTTP 响应散落在聊天窗口里，最后要么把单源被动子域当成确定资产写进报告，要么把真实的测试凭据贴进了云端模型。这套方法论把整个侦察过程收进结构化流程，每条产出都能追溯来源。

核心机制：置信度分级、证据固定、阶段流水线

置信度分级。 每条发现必须标记 TENTATIVE、FIRM 或 CONFIRMED。被动来源的单条子域记录最高只能算 TENTATIVE；DNS 能解析算 FIRM；多源汇聚或主动验证才算 CONFIRMED。归因遵循 rule of three：三条独立弱信号，或一条强加一条弱。这直接堵住单源定论这类常见错误。

证据卫生。 每个 artifact 记录 URL + UTC 时间戳 + SHA-256 + 工具版本 + run_id，原始 HTTP 响应截断到 2 KiB，证据目录只读、工作副本另存，临时页面先归档再引用。

五阶段流水线。 Seed Discovery（WHOIS、ASN、DNS、CT 日志）→ Asset Expansion（被动子域、云桶排列、typosquat）→ Enrichment（Shodan、TLS/JARM 指纹、SSO 指纹、GitHub dork、secrets sweep）→ Exposure Analysis（Nuclei 常驻检查、误配探测、CVE × EPSS × KEV 排序）→ Reporting。同阶段模块可并行。优先级上，泄露库（HudsonRock、HIBP、DeHashed）ROI 最高，往往直接产出企业 SSO 明文凭据；其次是代码搜索与云桶列举。

操作边界与 OpSec

• 授权前置。 目标必须属于自己或已有书面授权；授权不明时做一次 soft scope check，确认后不再追问。
• 检测感知。 每个操作打 Low / Medium / High 可检测性标签，默认只做被动探测；遇到 429、状态码漂移或 WAF 拦截，按退避阶梯降速、换模块、必要时停止并上报负责人。
• 凭据验证纪律。 发现的凭据只用只读 validator（如 sts:GetCallerIdentity）确认存活，不创建、不修改、不发送。
• 禁止事项。 不做主动利用与后渗透；不把真实 PII、会话 token 或 API key 送入云端 LLM；不对 favicon hash、共享 NS 等单信号做归属断言；不在明确的 --aggressive 模式之外跑 masscan、fuzzing 或 SMTP 用户枚举。

这套方法的价值不在于多发现几个资产，而在于交付时每条结论都能回答「凭什么相信」。

External Recon: Auditable Engineering Within Scope

In authorized external red team and ASM engagements, the hard problem is rarely "can't find assets." It's that once information piles up, you can no longer answer three questions: how confident is this finding, can the evidence be reproduced, and did any operation cross the engagement boundary. Screenshots, DNS records, and HTTP responses scattered across chat windows usually end with a single-source passive subdomain written up as a confirmed asset, or a real test credential pasted into a cloud model. This methodology wraps the entire recon process into a structured workflow where every output traces back to its source.

Core Mechanics: Confidence Tiers, Evidence Hygiene, Pipeline Stages

Confidence tiers. Every finding carries TENTATIVE, FIRM, or CONFIRMED. A single passive-source subdomain record is at most TENTATIVE; DNS resolution earns FIRM; CONFIRMED requires corroboration — multiple independent sources converging, or active verification. Attribution follows the rule of three: three independent weak signals, or one strong plus one weak. This directly kills the common error of single-source conclusions.

Evidence hygiene. Every artifact gets URL + UTC timestamp + SHA-256 + tool version + run_id. Raw HTTP captures are capped at 2 KiB body. The evidence store stays read-only; working copies live elsewhere. Ephemeral pages are archived before being cited.

Five-stage pipeline. Seed Discovery (WHOIS, ASN enum, DNS records, certificate transparency) → Asset Expansion (passive subdomains, bucket permutations, typosquats, Wayback CDX) → Enrichment (Shodan InternetDB, TLS/JARM fingerprinting, SSO fingerprinting, GitHub dorking, secrets sweep) → Exposure Analysis (Nuclei always-on checks, misconfig probes, CVE × EPSS × KEV prioritization) → Reporting. Modules within a stage run concurrently. By priority, breach corpora (HudsonRock Cavalier, HIBP, DeHashed) deliver the highest ROI — often plaintext corporate SSO credentials — followed by code-search dorking and listable cloud buckets.

Operating Boundaries and OpSec

• Authorization first. Targets must be owned or covered by written authorization. When scope is unclear, run one soft scope check; once asserted, stop asking.
• Detection-aware probing. Each operation is tagged Low / Medium / High for detectability; passive sources are the default. On 429, status-code drift, or WAF block pages, follow a back-off ladder: halve concurrency, pivot to a different module, rotate fingerprints, or pause and escalate to the engagement lead.
• Credential validator discipline. Discovered credentials are confirmed with read-only validators only (/me, sts:GetCallerIdentity) — never create, modify, delete, or send.
• Hard prohibitions. No active exploitation or post-exploitation. No real PII, session tokens, or API keys into cloud LLMs. No single-signal ownership claims — favicon hashes, shared NS, and shared CT issuers are hypotheses. No masscan, fuzzing, or SMTP user enumeration outside explicit --aggressive mode.

The value of this methodology is not in finding more assets, but in being able to answer "why should we believe this" for every line of the final deliverable.