osint-methodology

OSINT 方法论 — 外部红队版

0. 适用场景 / 不适用场景

在以下场景使用此技能： 规划或执行经授权的外部侦察（红队、漏洞赏金、ASM）；绘制组织的攻击面；调查个人、实体或威胁行为者；制作面向客户的交付物。

在以下场景不要使用此技能： 用户需要主动利用、利用后操作或恶意软件开发；蓝队/检测相关内容；或目标授权尚不明确——应先询问范围问题。

---

1. 授权与法律立场

适用于操作人员拥有或获得书面授权进行评估的资产。

委婉确认范围——如果尚未确认授权，只询问一次：

“快速确认一下范围：这是你拥有或获得书面授权进行评估的目标吗？我想确保我们没有超出合作约定的边界。”

一旦对方确认，不要再次询问。如果已说明合作类型（“根据合同对 acme.com 进行渗透测试”），即可继续。

始终遵守的防护措施：

• 绝不削弱目标侧的身份验证、速率限制或安全控制。
• 除非明确启用 --aggressive 模式，否则不得进行破坏性探测（线速 SYN 扫描、masscan、模糊测试）。
• 绝不将真实的 PII、凭据、会话令牌或 API 密钥粘贴到托管于云端的大模型中。
• 绝不对记录范围之外的资产采取行动，即使它们“显然相关”也不例外。

---

2. 置信度级别

每项断言都必须标注置信度级别。

级别	含义
TENTATIVE	根据间接证据判断合理，但尚未验证。仅凭片段匹配的搜索运算符结果、根据姓名推断出的邮箱模式、来自单一被动来源的子域名。
FIRM	直接观察到，但未经交叉验证。子域名可解析；Shodan 返回了 banner；CT 日志条目。
CONFIRMED	多个独立来源交叉验证，或已直接验证。经实时验证的令牌；可列出内容的存储桶；三个来源共同确认的子域名。

归因三原则： 3 个独立的弱信号，或 1 个强信号 + 1 个弱信号。绝不基于单一来源进行归因。

2.1 置信度升级工作流

资产类型	TENTATIVE → FIRM	FIRM → CONFIRMED
子域名	≥2 个被动来源，或 DNS 可解析	在标准端口上提供服务，且返回 banner/证书
IP	≥2 个来源（被动 DNS、ASN、Shodan）	TCP SYN-ACK 或 ICMP 响应
WebApp	已提取 URL，但尚未访问	HTTP 返回 2xx/3xx/4xx，且 content-length > 0
邮箱	根据姓名推断模式，或仅凭片段匹配	在 Hunter/IntelX/泄露数据中列出，或 SMTP 250（在 DATA 阶段前中止）
存储桶	候选排列组合 + HEAD 返回 200/301/403（表示存在）	GET 列表 = CONFIRMED
凭据 / 密钥	在捕获的文本中匹配到正则表达式	只读验证器返回成功（记录范围 + 账户 ID）
人员	姓名来自单一来源	经第二个独立来源确认
SSO 租户	OIDC 发现端点返回元数据	提取租户 GUID，且通过 MX/autodiscover/SP 记录关联到域名

默认报告原则：未经明确的交叉验证，绝不声称已 CONFIRMED。如有疑问，降低置信度。

---

3. 输出格式

每项发现都使用此架构（可直接导入资产管理工具）：

Finding:
  id:          <stable hash or UUID>
  module:      <technique that discovered it>
  asset_key:   <typed key, e.g. sub:api.example.com>
  category:    <e.g. SECRET_LEAK, OPEN_GRAPHQL_API, SSO_EXPOSURE>
  severity:    <info|low|medium|high|critical>
  confidence:  <tentative|firm|confirmed>
  title:       <one-line summary>
  description: <2-5 sentences>
  evidence:
    url:       <where found>
    timestamp: <UTC ISO8601>
    sha256:    <hash of any downloaded artifact>
    raw:       <truncated to 2 KiB>
  references:  [<CVE-ID, advisory URL, vendor doc>]
  remediation: <action the asset owner can take>

始终使用 UTC 时间戳。

---

4. 来源规范与引用

每项材料都需包含：URL + UTC 时间戳 + SHA-256 + 工具版本 + run_id。

• 使用 SHA-256 对所有下载内容进行哈希。截图使用 PNG 格式。
• 原始 HTTP 捕获内容的正文上限为 2 KiB。JSONL 日志每个事件占一行。
• 将只读证据与工作副本分开；绝不编辑捕获的材料。
• 优先使用持久引用（CVE、ATT&CK 技术 ID、RFC）。如引用具有时效性，应先存档（archive.today、Wayback SavePageNow）。

---

5. 不要做

• 不要将凭据、会话令牌、真实个人身份信息或唯一关联线索粘贴到云端大模型中。敏感分析请使用本地模型。
• 不要假设厂商标签就是事实（TRM、Chainalysis、Arkham 的结论可能不同）。
• 不要根据单一信号断定归属（favicon 哈希、共享 NS、共享 CT 签发者都只是一个假设）。
• 不要在未明确启用 --aggressive 模式的情况下运行模糊测试、SYN 扫描、masscan 或 nuclei fuzzing/*。
• 除只读验证外，不要将凭据验证器用于任何其他用途。
• 不要把威胁行为者的能力等同于其意图。应将能力、意图和赞助方分别看待。
• 遇到主动防御时，不要升级行动——应停止并记录（§6.4）。

---

6. 操作安全

6.1 傀儡账号

建立发帖记录，让账号自然成长，并使用独立的浏览器配置文件。人设生成：Fake Name Generator、This Person Does Not Exist。浏览器隔离：Firefox Multi-Account Containers。使用一次性号码进行短信验证。安装前审核每个扩展程序。维护证据保管链：为每项操作添加时间戳，为每件证据计算哈希。

6.2 可检测性标记

为每项操作添加标记，以便分析留下的痕迹。

标记	示例
低	被动 Shodan InternetDB；crt.sh；Wayback CDX；SecurityTrails PDNS；Hunter.io；对公共存储桶发送 HTTP HEAD；getuserrealm.srf；获取 OIDC 元数据。
中	GetCredentialType 用户枚举；Okta /api/v1/authn 用户枚举；凭据验证；AWS sts:GetCallerIdentity；Swagger/GraphQL 探测；有针对性的 favicon 哈希 + JARM 指纹识别。
高	主动端口扫描（naabu/masscan/nmap）；对生产环境进行 Nuclei 完整扫描；大规模子域名暴力枚举；SMTP RCPT TO 枚举；Web 模糊测试。

默认设置：默认使用被动方式。仅在 (a) 明确授权，(b) 符合约定的时间窗口，且 (c) 操作人员了解日志量时，才进行主动探测。

6.3 验证器规范

在公开渠道发现凭据时，只能使用只读验证器（/me、auth.test、sts:GetCallerIdentity）确认其是否有效。绝不创建、修改、删除或发送任何内容。记录 checked_at（UTC 时间）+ 截断后的响应 + 作用域/账号 ID。9 家服务提供商的具体验证器端点见 offensive-osint §23。

6.4 考虑检测风险的探测

已被发现的迹象（严重程度递增）： 429 / Retry-After；验证码拦截页；WAF 阻止页面；状态码变化（仅你的 IP 收到的响应从 200 变为 403）；横幅变化；NXDOMAIN 回滚；蜜罐诱饵（无法通过验证的凭据）；直接联系。

退避步骤：

1. 将并发数减半；加入 2–10 秒抖动。
2. 停止访问触发问题的路径；改用其他模块。
3. 使用新的 User-Agent / TLS 指纹。
4. 轮换出口 IP（住宅代理、不同云区域）。
5. 暂停 1–24 小时。
6. 如果遇到 WAF 阻止、状态码变化或直接联系：停止并咨询项目负责人。

---

7. 外部红队侦察流水线

六个按顺序执行的操作阶段，随后进行报告，作为阶段后的工作；同一阶段内的模块可以并发运行。

阶段	执行内容
1 — 种子发现	WHOIS、ASN 枚举（HE BGP Toolkit、RIPEstat）、DNS 记录（A/AAAA/MX/TXT/NS/SOA/CAA）、CT 历史记录（crt.sh、Censys）。
2 — 资产扩展	子域名枚举（先被动 → 再排列组合 → 再暴力枚举）；云存储桶排列组合；生成仿冒域名；Wayback CDX；移动应用发现；DNS 遍历；LinkedIn 员工枚举；组织/子公司资产足迹（反向 WHOIS、企业注册信息）。
3 — 信息丰富	首次主动 Web 流量探测和身份信号收集：端口/服务（Shodan InternetDB → naabu）；TLS 握手（证书链、JARM、favicon mmh3）；WAF/CDN 推断；源站发现；安全标头；电子邮件收集；电子邮件安全审计；GitHub dorking；JS 深度分析；SSO/IdP 指纹识别（被动层级）；API 发现（被动分类器）；机密信息扫描（Postman、Stack Exchange）；供应商产品指纹识别；容器/CI-CD/云原生暴露面；招聘信息收集。
4 — 暴露面分析	批量主动探测：持续运行 Nuclei 检查；TLS 深度审计；泄露数据 × 身份关联 → SSO_EXPOSURE 发现项；针对性错误配置探测（.git/config、.env、/actuator/env、/_cat/indices、/console）；漏洞优先级排序（CVE × EPSS × KEV × POC）。
5 — 收敛	对第 2–4 阶段发现的主机名/资产进行一轮有界递归（重新变换、重新探测——而非无边界爬取）；后续跟进云足迹（例如从泄露的云访问密钥中提取账户 ID）；检查供应链名称是否可被认领（确认内部/限定范围的软件包名称尚未在公共注册表中被认领）。
6 — 主动验证	严格门控、由操作人员启用、经授权参与测试的验证层——默认关闭。针对自有面板提交实时凭据（默认凭据 + 泄露凭据重放）；主动确认云/容器/API/SSO；Host 标头注入 / 盲 SSRF；HTTP 请求走私差异测试；注入载荷确认（例如 XSS）；JWT 伪造身份验证绕过差异测试。此处每个模块除了需要参与测试授权 (§1)，还必须明确启用，并针对每个目标执行范围确认步骤。
报告 (阶段后)	为每项发现进行风险评分；导出资产图谱；面向客户端的报告（执行摘要 + 技术详情 + 修复建议）；复现材料包；如适用，提交漏洞赏金报告。

7.1 流水线优先级顺序（信号密度从高到低）

1. 泄露数据 — HudsonRock Cavalier + HIBP + DeHashed。投资回报率最高；通常能获取明文的企业 SSO 凭据。
2. GitHub 侦察 — 代码搜索 dork。获取 AWS 密钥、Slack 令牌、JWT 密钥最快的途径。
3. Nuclei 错误配置扫描 — 暴露的管理面板、具有公开 POC 的 CVE。
4. 云存储桶 — 可列出内容 = 严重。
5. 端口 — 优先使用 Shodan InternetDB。VPN 集中器、RDP、Jenkins、Elasticsearch 都是高价值切入点。
6. 电子邮件 OSINT — 为泄露数据提供线索；为钓鱼名单提供来源。
7. Web 技术 / WAF / 截图 — 对数千台主机进行分流。
8. Wayback — 归档 JS 中可能含有硬编码密钥；已移除的管理/开发路径。
9. DNS 深度分析 + 电子邮件安全 — SPF/DMARC 漏洞可被用于欺骗；TXT 令牌可揭示 SaaS 租户。
10. 证书 → TLS — CT 时间线可发现被遗忘的子域名；弱加密套件 = 易得发现项。
11. ASN + 反向 DNS — 企业 IP 地址空间中可能托管未公开的基础设施。
12. 仿冒域名 — 已注册 = 发现项；未注册 = 钓鱼候选名单。

7.2 时间预算与参与方案

阶段	小型组织（<100）	中型组织（100–1K）	大型组织（1K+）
1. 种子	30 min	30 min	30 min
2. 资产扩展	1–2 h	2–4 h	4–8 h
3. 丰富信息（每 100 个存活的 Web 应用）	~1 h	~1 h	~1 h
4. 暴露面分析	1–3 h	3–6 h	6–12 h
5. 收敛	15–30 min	30–60 min	1–2 h
6. 主动验证 (如已启用)	30 min–1 h	1–2 h	2–4 h
报告	2–4 h	4–8 h	1–2 天

方案： 1 小时快速评估（阶段 1–2 的被动探测 + 泄露数据 + 执行摘要）· 4 小时重点评估（增加电子邮件收集、SSO 指纹识别、仿冒域名）· 1 天标准评估（按优先级完成阶段 1–5）· 1 周深度评估（标准评估的全部内容 + JS 深度分析、移动端、云原生、供应商产品、软件包注册表；阶段 6 仅在获得明确的书面参与授权后执行）· 每周持续差异分析（重新运行阶段 1–3，并与基线进行差异比较）。

中止条件： 阶段 1 后发现范围不匹配；阶段 2 后攻击面接近于零——这表示某个类别中的每个连接器结果的并集都为空，而不只是某一个来源为空（§7.3）；任何阶段出现 WAF/检测迹象（§6.4）。

7.3 连接器韧性

任何单一数据源都不应成为整个类别的瓶颈。每个类别都应查询可互换的后端，并取结果的并集，而不是只调用一个来源——CT 日志（crt.sh、Censys、certspotter）、被动 DNS（多个提供商）、主机情报（Shodan、Censys、Netlas）、反向 WHOIS（多个供应商）——并在并集查询层下方跟踪各来源的健康状态，并缓存结果，且缓存 TTL 应较短。

• 受速率限制或已失效的来源会降低该类别的产出，但绝不能在不作提示的情况下使其结果归零。
• 将故障记录为单个来源的健康状态事件，而不是“类别为空”。阶段 2 的中止判断（§7.2）依据并集结果，而不是某个来源的状态。
• 为每个来源的结果设置 TTL：既要足够短以保持数据新鲜，也要足够长以覆盖该来源的速率限制窗口——参与期间重新运行，不应再次消耗已经用掉的配额。

这一原则将 crt.sh 式的回退做法推广到所有类别，而不仅限于证书：单个 API 失效是需要记录并绕开的覆盖度下降事件，而不是地图上的空白。

7.4 阶段编号 ≠ 默认安全

模块的阶段编号表示它何时运行，而不是它是否为被动操作。不要仅凭模块所在阶段来判断其可检测性；应始终检查模块自身的门控标志。

技术	阶段	实际门控条件
IDOR/BOLA 差分确认	3（信息丰富）	模块自身的 --active/--deep 标志——而不是阶段边界
主动用户枚举预言机（IdP）	3（信息丰富）	模块自身的 --deep 标志
有界的 401/403 绕过 / 参数挖掘	4（暴露面）	默认受速率限制；此阶段不设门控
凭据重放 / 默认凭据提交	6（主动验证）	明确启用 + 确认范围
JWT 伪造身份验证绕过差分	6（主动验证）	明确启用 + 第二个确认标志

阶段 6 是流水线中唯一明确按设计包含所有侵入性操作的阶段（默认关闭，由操作员启用）——但阶段 1–5 只是大多属于被动到低侵入性操作，而“大多”掩盖了真实的例外，例如上面列出的两个阶段 3 操作。可检测性按技术单独标记（§6.2），绝不能根据某项技术恰好所属的流水线阶段推断。

---

8. 资产图谱规范

每项发现都是图谱中的一个类型化资产，而不是一个游离的字符串。

8.1 资产分类

类别	类型
DNS / 网络	domain、subdomain、ip、netblock、asn
服务	port、service、certificate
身份	email、person、credential
代码 / 配置	repo、secret
云 / 存储	bucket、firebase_project
Web	webapp、wayback_endpoint、api_endpoint、api_spec、graphql_schema
移动端	mobile_app、deep_link、exported_component
钓鱼	typosquat_domain
SaaS	postman_collection、postman_workspace、postman_api_key、stack_post、saas_public_surface

每项资产都包含：type、key（类型化去重 ID）、value、sources[]、confidence、first_seen、last_seen、attrs{}。

**规范：**先创建资产，再关联发现项。按 key 去重。sources[] 必须列出所有来源。置信度按来源分别计算，再汇总。

8.2 资产级分诊规则

**WebApp 优先级（从高到低）：**身份验证（auth.、login.、sso.）→ 管理路径 → 开发 / 暂存主机 → API（api.、gateway.）→ 面向客户的站点（portal.、app.）→ 营销站点。

**电子邮件优先级：**高管（CEO/CFO/CISO）→ IT/帮助台/安全 → 开发人员/工程师/DBA → 销售/HR/财务 → 通用角色账户。

**Repo 优先级：**最近推送（过去 30 天）> 陈旧；描述中包含目标名称的公开 Repo > 仅含代码的 Repo；名称中提及 prod/internal/secret → 即使公开也属于高优先级。

---

9. 发现项评级标准与严重性映射

严重性判定标准

严重性	判定标准
CRITICAL	预身份验证代码执行；已确认有效的凭据；可列出生产数据；根本性的信任违规。示例：.env 暴露、包含 PII 且可列出内容的 S3 存储桶、经实时验证的 AWS 管理员密钥、允许匿名身份验证的开放 Kubernetes API、泄露数据集中有 ≥10 名员工且已识别出所属租户。
HIGH	存在显著暴露且有明确的升级利用路径；披露高价值信息。示例：GitHub Repo 中存在公开密钥、可能发生子域名接管、允许携带凭据的反射型 CORS、暴露的 Jenkins/phpMyAdmin 管理界面、生产环境开放 GraphQL 内省、DMARC p=none。
MEDIUM	信息披露、安全加固缺失、暴力破解风险。示例：缺少 HSTS/CSP、Apache /server-status、JS 中包含内部 IP/主机名、错误页面泄露架构、android:allowBackup=true、用户数据 API 使用通配符 CORS、Slack webhook 泄露。
LOW	外观问题或影响轻微的缺陷。示例：缺少 X-Frame-Options、.DS_Store 暴露、Stripe 测试密钥、缺少证书固定、WordPress 版本过时（无已知的在用漏洞利用）。
INFO	值得记录；无需立即采取行动。示例：robots.txt 暴露路径、已锁定的私有存储桶、未启用 DNSSEC。

严重性升级规则

• 身份验证 / 登录 / SSO / 管理路径缺少 HSTS → MED → HIGH。
• 通配符 CORS + 凭据标头 → MED → HIGH。
• 端点兴趣评分 ≥70（配套技能 §20）→ 至少为 HIGH。
• 域名泄露涉及 ≥10 名员工 → 无论是否存在数据陈旧方面的 caveat，均为 CRITICAL。
• 供应商产品版本与 CISA KEV 匹配 → CRITICAL。

---

10. 枢轴模式与规模策略

方面	调查模式	攻击性侦察模式
探测速率	缓慢、单线程，与流量融为一体	突发式并行探测，按服务提供商限速
OpSec 姿态	仅使用傀儡账号；绝不暴露调查人员身份	以项目参与者身份开展；团队可能会通知 SOC
证据处理	符合法庭标准的保管链	符合项目标准；采用相同的哈希值／时间戳规范
报告格式	叙述 + 有来源支持的时间线	按资产列出发现 + 修复建议 + 复现步骤

规模策略：

• 小型（<100）： 聚焦个人账户。攻陷一位高管／CFO 的账户往往就能拿到关键权限。深入检查每封邮件 + 每项身份体系发现。检查创始人的个人 GitHub 组织。
• 中型（100–1K）： 均衡枚举。按标准深度运行完整管线。按职位确定 LinkedIn 优先级。检查两个应用商店。
• 大型（1K–10K）： 先广后深；自动化发现资产；仅对发现结果进行人工分流。
• 超大型／集团企业： 缩小范围是最重要的一步。先绘制品牌枢轴图。与个人账户相比，泄露语料库和系统性安全态势发现（DMARC 缺口、SSO_EXPOSURE 范围）更为重要。

---

11. 实现：配套技能指引

以下模块在 offensive-osint 中提供完整的实现细节——探测路径、字典、curl 单行命令、正则表达式和评分标准。此技能定义要做什么；该技能定义如何做。

身份体系映射（offensive-osint §22）— Microsoft Entra（OIDC 元数据、getuserrealm.srf、GetCredentialType）、Okta（slug 推导、/api/v1/authn）、ADFS、Google Workspace、通用 OIDC（Auth0/Keycloak/Ping/OneLogin/Duo）、SAML 元数据（5 条路径）、AWS 账户 ID 提取、M365 深度攻击面（Teams 联合身份验证、SharePoint、OneDrive、OAuth client_id、设备代码钓鱼检查、Power Platform）。

API 与认证映射（offensive-osint §16.1–16.2、§20）— 包含 28 条路径的 Swagger/OpenAPI 字典；包含 13 条路径的 GraphQL 字典；introspection POST 正文；禁用 introspection 时的字段建议枚举；端点关注度评分 0–100 标准。

JavaScript 深度分析（offensive-osint §13 模式）— sourcemap 检测；在 JS 正文和 sourcesContent[] 中检索机密目录；三级端点提取正则表达式；内部主机泄露模式；Next.js 清单解析。

移动攻击面（offensive-osint §21）— Android/iOS 应用发现；所有权置信度 0–100 评分；APK 静态分析；清单错误配置发现；Firebase 规范探测。

云攻击面（offensive-osint §16.8）— S3/GCS/Azure 存储桶排列组合（6 个前缀 × 15 个后缀）；HEAD → GET 探测技术；云原生指纹（Lambda、Cloud Run、Azure Functions、Vercel、Netlify、Workers）；K8s/etcd/kubelet/容器注册表暴露。

WAF / CDN 绕过与源站发现（offensive-osint §16.15）— DNS 历史记录枢轴；证书 SAN 枢轴；favicon mmh3 + JARM 聚类；通过 Host 标头直接探测 IP；邮件／ftp/cpanel 例外；错误页面信息泄露；邮件标头退信技巧；置信度规则。

漏洞优先级排序（offensive-osint §29.2）— NVD、EPSS、CISA KEV、ExploitDB、Metasploit、InTheWild.io、Trickest CVE→POC；9 项信号评分标准 → P0/P1/P2/P3 等级。

钓鱼基础设施（电子邮件安全参见 offensive-osint §16.14）— 通过 dnstwist 生成近似域名候选清单；利用受信任域名的子域名接管实施钓鱼；电子邮件伪造可行性矩阵（SPF × DMARC）；根据 OSINT 信息（职位名称、近期事件、供应商关系、GitHub 提交记录）制定借口。

12. 泄露 × 身份关联

对外部红队来说，这是单项投入产出比最高的技术。每次参与都要执行。

来源	层级	备注
Hudson Rock Cavalier	免费	信息窃取程序日志语料库；企业 SSO 凭据的信号极强。
Have I Been Pwned	免费 + 付费	检查整个域名是否存在泄露记录 + Pwned Passwords（k-匿名性）。
DeHashed	付费	可按记录搜索的 API。
IntelX	免费 + 付费	聚合器；支持电话簿搜索。

域名级严重程度： ≥10 名员工的账号遭到泄露 → 严重；1–9 名 → 高；≥1 名终端用户 → 中；域名出现但没有具名账号 → 信息。

SSO_EXPOSURE： 在完成阶段 3 的身份体系映射和泄露查询后，将发现的 IdP 租户域名与泄露语料库取交集。交集非空 → 生成 SSO_EXPOSURE 发现项，严重程度为严重。证据：租户 ID + 产品 + 员工人数 + 每个账号的来源。

窃取程序日志处理规范： 静态加密；为每件材料计算 SHA-256；绝不将明文密码粘贴到云端大模型；维护证据保管链；默认在客户报告中隐藏密码（可另行提供加密凭据包）。

12.1 个人身份档案

域名级泄露数量（见上文）可以说明组织存在泄露风险。身份档案则会告诉你具体是谁——将每个发现的 PERSON（姓名、职位、资历、来自 person-enum/LinkedIn dorking 的目标评分）与按电子邮件匹配的任何泄露 CREDENTIAL 关联起来，为每个人生成一张排名卡片。这一步可以将泄露人数转化为鱼叉式网络钓鱼／凭据填充目标名单。

关联键是电子邮件地址，而不是姓名。 PERSON 资产以姓名为键，通常自身不带电子邮件地址——关联前，须根据组织的已确认电子邮件格式（由 Hunter 推断或通过独立观察得出）解析姓名→电子邮件。绝不能仅凭单个样本猜测格式后进行关联。

字段	来源
职位／资历／目标评分	person-enum / LinkedIn dorking
电子邮件——known（直接观察到）或 pattern（将姓名套入组织已确认的格式）	电子邮件 OSINT / 组织电子邮件格式
与该电子邮件关联的所有凭据	泄露数据集、窃取程序日志、GitHub/JS 基本身份验证泄露、泄露重放命中
风险等级	推导得出，见下文

风险分级： 高价值邮箱（高管／IT／管理员，目标评分 ≥80）遭到泄露且至少有 1 个已确认凭据，是最严重的情况。

目标评分	泄露的凭据	风险
≥80（高管／IT／管理员）	≥1	严重
任意	≥1	高
≥80	0	中
<80	0	低

孤立凭据： 泄露的电子邮件地址即使无法关联到任何已发现人员，仍然是线索，而非死胡同——应单独列出，并按泄露记录数量排序。只是尚未确定对应人员；进一步执行 person-enum 可能会找到对应人员。

置信度： 关联的可靠程度取决于电子邮件解析的可靠程度。known 电子邮件沿用凭据自身的置信度（§2）；出于归属判断的目的，pattern 解析出的电子邮件在地址本身通过独立观察确认之前始终为 TENTATIVE（例如，该地址原样出现在泄露记录中，或 Hunter.io 直接返回该地址）——绝不能仅凭格式推断，将基于 pattern 的档案报告为 CONFIRMED。

只要某次参与同时有阶段 3 person-enum／电子邮件 OSINT 输出和泄露查询结果（域名级或重放），就执行此步骤——这是对已收集数据进行关联，无需新增收集，因此没有理由跳过。使用输出结果决定优先向谁投放钓鱼借口（§13），以及谁最适合作为只读凭据检查的高价值候选人（§6.3）。

---

13. 专业 OSINT 领域

加密货币 — 使用 Cielo、TRM、Arkham、MetaSleuth 追踪资金流。L2/rollup：从 L1 桥接事件入手；使用 L2 浏览器查看 rollup 内的活动。注意：桥接会铸造/销毁代币（避免假设资金流一一对应）；MEV 路径会产生虚假的直接追踪线索。

图像 / 视频 / 时间定位 — 反向图片搜索（Google Lens、Yandex、TinEye）；使用 ExifTool 查看 EXIF；使用 Forensically/FotoForensics 进行取证；通过前景和背景地标分析、Street View、Overpass Turbo、PeakVisor 进行地理定位。阴影分析：SunCalc、ShadeMap。卫星图像：Google Earth Pro 历史影像、Sentinel Hub。

威胁行为者调查 — 确定范围：根据 CERT/供应商报告提出行为者假设 → 收集 IOC → 通过 CT 日志线索关联、共享主机、NS 复用、HTML 指纹映射基础设施 → 分析制品特征（PDB 路径、Rich 标头、SSDEEP/YARA）→ 通过社交信息关联（用户名、代码片段、招聘信息）。归因准则：三项规则；区分能力与意图；优先采用持久线索（代码签名证书、构建路径惯例），而非短暂线索（可解析的 IP）。俄罗斯线索：EGRUL、Rusprofile、hh.ru、VKontakte。中国线索：gsxt.gov.cn、Tianyancha、ICP 备案、Weibo、Zhihu。

人员与社交媒体 — 用户名枚举：WhatsMyName、Sherlock、Maigret。人脸搜索：PimEyes、Exposing.ai。社交关系图谱：Maltego、SocialBlade。Bluesky：通过 bsky.social/xrpc/ 解析 DID，通过 Firesky 获取 firehose。Mastodon：通过 WebFinger 发现实例；使用 FediSearch 跨实例搜索。

---

14. 反模式与常见失败模式

• 依据单一来源进行归因。 遵循三项规则。
• 将供应商标签当作事实。 标签只是待验证的假设。
• 将 favicon 哈希匹配等同于归属关系。 共享基础设施、共享 CMS、共享 CDN 都会产生匹配结果。
• 仅凭搜索摘要中的 dork 就标记为 CONFIRMED。 在访问目标前，应标记为 TENTATIVE。
• 将真实 PII / 凭据粘贴到云端大模型中。 仅使用本地模型。
• 以己度人地揣测威胁行为者。 他们的思维方式与你不同。
• 依据 IP 地理位置进行归因。 VPN 和住宅代理确实存在。
• 忽略 CT 日志延迟。 未发现不等于不存在；延迟可能从几分钟到几小时不等。
• 将 Wayback 记录视为“时间 T 时的网站”。 这是尽力而为；许多请求会失败。
• 允许资产图谱中出现无类型的字符串。 每项发现都是一项资产。
• 跳过范围检查。 有疑问时就问一次。
• 忘记使用 UTC。 本地时间会造成关联错误。
• WAF 封锁后仍继续探测。 应暂停操作（§6.4）。
• 跳过置信度提升的文档记录。 TENTATIVE 必须有升级为 CONFIRMED 的路径。
• 将执行摘要视为事后才考虑的事项。 在项目开始时就规划交付物。

---

15. 漏洞赏金提交与负责任披露

平台： HackerOne（基于 CVSS）· Bugcrowd（VRT：P1–P5）· Intigriti · YesWeHack · HackenProof（专注加密货币）· Open Bug Bounty（仅限 XSS/SSRF）· 对未纳入项目计划的目标，可使用 /.well-known/security.txt。

报告结构：

Title: [Severity] [Component] Brief description
Summary: 2-3 sentences — what and why it matters.
Steps to Reproduce: numbered, copy-pasteable, URL + payload + expected vs actual.
Proof of Concept: screenshot or sanitized HTTP request/response.
Impact: what data/users/functions are at risk.
Severity: CVSS v3 vector + score + 1-sentence justification.
Remediation: concrete, actionable recommendation.

未纳入项目计划的 CVD： 检查 security.txt → security@<target> → WHOIS 滥用联系信息 → CERT/CC。公开披露前的标准等待期为 90 天。绝对不要： 包含他人的 PII、在等待期结束前公开发布，或先通过社交媒体升级处理。

---

16. 客户交付模板

执行摘要结构： 项目元数据 → 前 3–5 项发现（标题 + 业务影响 + 修复工作量）→ 态势观察（电子邮件安全、身份体系、云攻击面、移动设备）→ 汇总指标（资产、按严重性分类的发现、已确认的有效凭据）→ 带时间线的后续建议。

单项发现报告卡： 标题 + 严重性 + 置信度 + 资产标识 + UTC 时间戳 → 描述 → 证据（URL + 工具 + 截图 + 原始 HTTP + SHA-256）→ 复现步骤 → 业务语言描述的影响 → 修复措施（立即 / 短期 / 长期）→ 参考资料 + 攻击路径提示。

风险解读（示例）：

技术描述	业务语言
可列举的含 PII 的 S3 存储桶	客户记录可被公开下载。可能触发 GDPR/CCPA 通知义务。
暴露的 .env 文件中含数据库凭据	可完全访问数据库；并可进一步访问备份、计费数据和员工 PII。
有效的 AWS 管理员密钥	云环境完全失陷；可启动加密货币挖矿程序、窃取全部数据并进行横向移动。
DMARC p=none	互联网上的任何人都可以发送看似来自贵域名的电子邮件。
≥10 名员工出现在泄露数据集中	被盗的公司 SSO 凭据正在流通；存在凭据填充攻击风险。
供应商设备列入 CISA KEV	攻击者正在主动扫描互联网，寻找这一确切漏洞。立即打补丁。

报告节奏： 第 1 天下班前发送启动摘要 → 项目中期首次发现 CRITICAL 时发送预警 → 项目结束时发送初步报告（前 5 项发现）→ 在约定的 SLA 内提交最终报告 → 修复后为 CRITICAL/HIGH 发现提供复测服务。

复现包： run-log.jsonl + assets.db + findings.db + evidence/（截图、HTTP 抓包、带有 .sha256 的下载文件）+ re-test-script.sh + 项目元数据。

---

17. 技能自测

在新会话中输入以下内容，确认技能已正确加载。

1. "对 acme.com 进行外部侦察（在授权范围内的漏洞赏金计划）。从哪里开始？" → §0、§1、§7、§7.1。
2. "不主动探测，如何区分 Entra、Okta 和 ADFS？" → §11 + 配套技能 §22。
3. "50 个子域名、12 个 Web 应用、23 个电子邮件地址——如何确定分流顺序？" → §8.2 + §7.1。
4. "在 GitHub 仓库中发现有效的 AWS 密钥。应该验证吗？" → §6.3。
5. "探测收到 429 响应，还有 Cloudflare 验证页面。接下来怎么办？" → §6.4。
6. "已收集 200 个电子邮件地址，组织使用 Entra。下一步投资回报率最高的行动是什么？" → §12、§12.1。
7. "目标完全处于 Cloudflare 之后。如何找到源站？" → §11（WAF/CDN 指引）+ 配套技能 §16.15。
8. "Nuclei 扫描发现 100 个 CVE。如何确定优先级？" → §11（漏洞优先级指引）+ 配套技能 §29.2。
9. "授权项目要求提供网络钓鱼可行性候选清单。" → §11（网络钓鱼指引）。
10. "在 HackerOne 目标上发现未认证的 POST 端点。撰写报告。" → §15。
11. "为 2 个 CRIT、5 个 HIGH、12 个 MED 的发现撰写执行摘要。" → §16。
12. "对 chase.com 运行完整的子域名枚举。" → §1（检查范围；不应运行）。
13. "项目中途 crt.sh 开始返回 429 响应——子域名列表完整吗？" → §7.3。
14. "某模块在阶段 3 运行。可以假定它是被动的吗？" → §7.4。
15. "我们有泄露数据命中记录和一份 LinkedIn 员工名单——应该优先关注哪些人？" → §12.1。

---

18. 更新日志

• v2.3 (2026-08-06) — §7 从 5 阶段模型升级为经实战验证的 6 阶段模型（Seed → Asset Expansion → Enrichment → Exposure Analysis → Convergence［有界递归 + 云足迹 + 供应链］→ Active Validation［严格门控、由操作人员启用、默认关闭］），并将 Reporting 重新定位为阶段后的工作；新增 §7.3 连接器韧性（按数据类别使用联合查询和可互换后端，逐个来源跟踪健康状态，因此某个来源宕机或触发速率限制不会导致某个类别的数据归零）和 §7.4 阶段编号 ≠ 默认安全（模块所属阶段并不能说明它是否为被动操作——务必检查其自身的门控标志；可检测性因技术而异）。新增 §12.1 个人身份档案——通过电子邮件，将发现的 PERSON 角色／资历与泄露的 CREDENTIAL 关联，生成按优先级排序的鱼叉式钓鱼／凭证填充目标列表，并包含风险分级和孤立凭证处理方式。新增 3 个自测提示词（§17.13–15）。
• v2.2 (2026-04-29) — 重构：从 1,694 行精简至约 480 行。将实现细节章节（§11–§15、原 §27–§31）压缩为指向 offensive-osint 的链接。保留完整的框架核心：置信度级别、流水线、资产图谱、严重性评估标准、OpSec、泄露关联、反模式和交付物模板。删除重复内容；将专业领域合并至单个 §13；将 §23–§25 合并至 §13；将 §27–§29 压缩为 §11 的指引内容。
• v2.1 (2026-04-27) — 根据 32 个提示词的烟雾测试差距分析进行了全面扩展。通过率：31/32。
• v2.0 (2026-04-27) — 进行重大改写，以适应外部红队工作方式。
• v1.x — 基于 SnailSploit/offensive-checklist 的原始框架。