osint-methodology

Name: osint-methodology
Author: elementalsouls

github.com/elementalsouls安全5.3k277 次安装今天更新

代码仓库

关于 osint-methodology

osint-methodology 为经授权的外部侦察和 OSINT 调查提供结构化方法，适用于红队、ASM 及证据整理工作。它强调授权范围、证据置信度、来源记录和可复现报告，并明确将主动利用排除在范围之外。

主要功能

01按授权范围开展外部侦察
02为发现结果标注置信度等级
03提供资产置信度升级流程
04记录证据来源、时间戳与哈希
05按操作可检测性分类
06规范调查发现与报告格式

适用场景

01梳理组织的外部攻击面与资产
02核验子域名、端点及泄露凭据线索
03调查人物、实体或加密货币流向
04整理可复现的客户报告和证据包

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/elementalsouls/claude-bughunter --skill osint-methodology

安装后在 Claude Code 中输入/osint-methodology确认已加载。

附带文件README.md

详细介绍

OSINT 方法论 — 外部红队版

0. 何时使用此技能／何时不使用

在以下情况下使用此技能：

规划或执行针对已获授权目标的外部侦察（红队、范围内的漏洞赏金项目、ASM 项目）。
端到端绘制组织的外部攻击面（子域名 → 资产 → 暴露面 → 攻击路径）。
调查个人、实体或威胁行为者，且需要严谨处理证据。
追踪加密货币流向、对媒体进行地理定位、开展图像／视频取证，或对事件进行时间定位。
构建结构化 OSINT 行动，且需要确保可复现、进行严重程度分级并顺利交接。
根据攻击性测试项目制作面向客户的交付成果（执行摘要、技术报告、复现材料包）。

在以下情况下不要使用此技能：

用户要求主动利用漏洞、利用后操作、横向移动、AD 权限提升、恶意软件开发，或任何超出侦察范围的内容——这些都不在适用范围内。
用户要求蓝队／防御内容（SIEM 规则、检测工程）——这属于不同领域。
目标的授权状态不明确，且用户要求你针对其不拥有的第三方资产采取行动——请参阅下方 §1；在继续之前，温和地询问范围问题。

1. 授权与法律立场

此技能适用于操作者拥有或已获得书面授权评估的资产（红队参与规则、漏洞赏金范围内资产、ASM 合同）。

温和确认范围： 如果用户要求你针对某个目标采取行动，而对话中此前未确认授权，请在继续之前询问一次：

“先快速确认一下范围：这是你拥有或已获得书面授权评估的目标吗（例如红队项目、范围内的漏洞赏金资产，或你自己的基础设施）？我想确保我们没有超出项目范围。”

一旦用户确认已获得授权，就继续操作，无需再次询问。如果用户明确说明了项目类型（例如，“这是我们根据合同对 acme.com 进行的渗透测试”），就不需要再次询问。

始终适用的防护措施（无论是否获得授权）：

绝不削弱目标端用于执行范围限制的身份验证、速率限制、横幅或任何安全控制。
除非明确启用 DEEP／--aggressive 模式，否则绝不执行破坏性探测（在生产环境中进行真正的 SYN 扫描、以线路速率运行 masscan、模糊测试／暴力破解）。
绝不将真实个人身份信息、有效凭据、会话令牌、API 密钥或其他机密粘贴到云端大模型或第三方服务中。
绝不对文档范围之外的资产采取行动，即使这些资产“显然有关联”（子公司、供应商、员工个人账户等）。

2. 置信度等级

在项目期间作出的每项断言都应标注置信度。共有三个等级：

等级	含义	示例
TENTATIVE（初步）	基于间接证据，具有合理可能性；尚未验证。	仅搜索摘要匹配 Google dork；根据姓名推断电子邮件格式；仅由一个被动数据源返回的子域名；favicon 哈希重合（两个主机共用一个 favicon——可能是共用基础设施，也可能只是巧合）。
FIRM（有力）	已直接观察到，但尚无佐证。	能解析到 IP 的子域名；通过 HEAD 请求确认存储桶存在（私有）；CT 日志中出现证书记录；Shodan 返回横幅信息。
CONFIRMED（已确认）	有多个独立佐证，或已直接验证。	已验证有效的 PMAK 令牌（只读 `/me` 返回 200）；泄露数据语料库、crt.sh 和 DNS 结果一致；存储桶可列出且文件可检索；已枚举出用户，且密码重置流程返回有效提示。

归因三原则： 断言关联关系前，需要三个独立的弱信号，或一个强信号加一个弱信号。不要仅依据单一来源进行归因。

2.1 置信度升级工作流

置信度并非一成不变——每个 TENTATIVE 资产都应有明确的升级路径，先达到 FIRM，再达到 CONFIRMED。请按以下各资产类型的规则执行。

资产类型	TENTATIVE → FIRM	FIRM → CONFIRMED
子域名	由 ≥2 个独立的被动来源返回，或 DNS A/AAAA/CNAME 解析成功。	在标准端口（80/443/22 等）上提供服务，且返回 HTTP 横幅、TLS 证书或 SSH 横幅。
IP	通过 ≥2 个来源发现（被动 DNS、ASN 查询、Shodan）。	主动探测收到响应（至少一个端口返回 TCP SYN-ACK，或收到 ICMP 回显应答）。
WebApp	从 JS/API/存档中提取 URL，但尚未访问。	HTTP 请求返回 2xx/3xx/4xx（任何非网络错误响应），且 content-length > 0。
Email	根据姓名模式生成，或由仅返回摘要的 dork 查询返回。	列在 Hunter.io/EmailRep/IntelX/泄露数据集中，或 SMTP 探测的 `MAIL FROM`/`RCPT TO` 返回 250（不投递邮件——在 DATA 阶段中止）。
Bucket（S3/GCS/Azure）	排列组合候选项；尚未探测。	HEAD 返回 200、301 或 403（确认其存在）。之后，当 GET 返回对象列表或成功获取已知对象时，升级为 CONFIRMED。
端点（API / wayback）	从 JS 正则、Wayback 或 Postman 中提取。	HTTP 请求返回非 404 响应（路由存在）。之后，当端点的行为完成指纹识别（认证状态、响应结构、速率限制）时，升级为 CONFIRMED。
凭据 / 密钥	与捕获文本中的目录正则匹配。	只读验证器（`/me`、`auth.test`、`sts:GetCallerIdentity`、`/user`）返回成功。之后，记录明确的作用范围和账户 ID，再升级为 CONFIRMED。
人员	从单个来源提取姓名（LinkedIn/泄露数据/GitHub 提交记录）。	由第二个来源确认（Hunter.io 职务信息 + LinkedIn 个人资料，或两个泄露数据来源包含相同邮箱）。
Repo	在 GitHub 搜索中，名称与组织关键词匹配。	Repo 元数据显示已确认的组织/邮箱/网站匹配。之后，当提交历史显示有员工参与时，升级为 CONFIRMED。
移动应用	在应用商店中名称匹配。	所有权置信度评分 ≥70（见配套技能 §21）。之后，当二进制元数据（签名证书、包名、开发者账户）与目标关联时，升级为 CONFIRMED。
证书	crt.sh 返回一次。	至少在 ≥2 个日志中确认 CT 日志条目。之后，当证书在已发现的主机上提供服务时，升级为 CONFIRMED。
SSO 租户	Discovery 端点返回 OIDC 元数据。	提取租户 GUID，且该域名通过租户预期的 MX/autodiscover/SP 记录解析。

**默认报告原则：**没有明确的佐证，绝不声称状态为 CONFIRMED。如有疑问，降低置信度。运营人员更信任谨慎的说法，而非夸大的断言。

3. 输出格式约定

在活动会话期间生成发现项时，请按以下架构整理每项发现，以便直接导入资产管理工具。

Finding:
  id:           <stable hash or UUID>
  module:       <which technique discovered it; "manual" if hand-found>
  asset_key:    <typed key, e.g. sub:api.example.com or webapp:https://example.com/admin>
  category:     <e.g. SECRET_LEAK, MISSING_HSTS, OPEN_GRAPHQL_API, LEAKED_CRED, SSO_EXPOSURE>
  severity:     <info|low|medium|high|critical>
  confidence:   <tentative|firm|confirmed>
  title:        <one-line summary>
  description:  <2-5 sentences>
  evidence:
    url:        <where it was 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 格式截图（无损；用于证据包时，比完整网页 WARC 更小）。
捕获原始 HTTP 请求/响应；正文上限设为 2 KiB，以控制证据包大小。
使用 JSONL（NDJSON）日志，每个事件占一行，并包含 run_id，以便重放整个项目。
将只读证据与工作副本分开；切勿编辑捕获的材料。

在输出中引用来源时，优先选择持久性较强的参考资料（CVE、供应商公告、ATT&CK 技术 ID、RFC），而非时效性较强的来源（Twitter 帖子、论坛主题）。如果来源只有时效性较强的材料，请先将其存档（archive.today、Wayback SavePageNow），再进行引用。

5. 切勿（硬性规则）

切勿将凭据、会话令牌、API 密钥、真实个人身份信息、信息窃取程序日志或独特的调查线索粘贴到云端大模型（ChatGPT、Claude.ai、Gemini、Perplexity）中。敏感分析请使用本地模型（Ollama、LM Studio、GPT4All）。
切勿假设供应商标签就是真相。交叉核验标签：TRM、Chainalysis、Arkham 的判断可能不一致。将每个标签都视为假设。
切勿假设跨链桥转账是一对一的。跨链桥、混币器和封装资产会引入铸造／销毁语义；请通过链上证明进行验证。
切勿仅凭单一信号断言所有权。Favicon 哈希重合、共享 CT 颁发者、共享 NS——每一项都只是一个假设。需要满足三项规则。
除非明确启用 DEEP 模式或 --aggressive，否则切勿运行模糊测试、SYN 扫描、masscan 或 nuclei fuzzing/* 模板。
除只读验证外，切勿将凭据验证器用于其他用途（不得创建／删除／发送）。
切勿镜像思维（假设目标与自己的思维方式相同）。区分能力、意图和赞助关系。
切勿混淆相关性与控制权。
遇到主动防御时，切勿升级操作；应停止并记录（见 §6.4）。

6. 操作安全

6.1 傀儡账号

傀儡账号是一个无法与你关联的虚假账号。建立发帖记录，让账号逐渐显得自然，并通过单独的浏览器配置文件使用它。

资源与技巧：

人设生成：Fake Name Generator、This Person Does Not Exist。
浏览器隔离：Firefox Multi-Account Containers，或为每个人设使用专属配置文件。
一次性电话号码：Burner、Silent Link（部分平台会拒绝 VoIP 号码——请预留一批号码）。
为任何高价值人设使用硬件通行密钥；将恢复代码离线保存。
安装前审核每个浏览器扩展。针对热门扩展的供应链攻击曾多次以调查人员为目标——应认为热门扩展的风险更高，而非更低。
维护证据保管链：为每项操作添加时间戳，对每个关键工件计算哈希，并按案件记录工具版本。
人设应看起来像真实的低活跃度账号：个人资料照片（合成）、简介，以及在使用该人设前数周内分散发布的几条随意帖子。

参考资料：

6.2 可检测性与 OpSec 标记

每次探测都会留下痕迹。在笔记中为每项操作标记可检测性级别，以便判断在目标一侧留下了怎样的 SIEM 记录。

标记	示例
低	被动查询 Shodan InternetDB；CT 日志查询（crt.sh）；Wayback CDX；被动 DNS（SecurityTrails）；Hunter.io 邮箱信息补充；对公开存储桶发送 HTTP HEAD 请求；`getuserrealm.srf`；获取 Microsoft OIDC 元数据。
中	Microsoft `GetCredentialType` 用户枚举；Okta `/api/v1/authn` 用户枚举；Postman API 密钥验证；AWS `sts:GetCallerIdentity`（记录到 CloudTrail）；Slack `auth.test`；整页截图；针对 28/13 路径字典的 Swagger/GraphQL 探测；定向 favicon 哈希 + JARM 指纹识别。
高	主动端口扫描（naabu / masscan / nmap）；针对生产环境运行完整 Nuclei 模板；大规模子域名暴力枚举；从第三方镜像下载 APK；对每个租户进行超过 N 次的深度模式用户枚举；SMTP `RCPT TO` 枚举；Web 模糊测试（ffuf/gobuster）。

与客户合作时，请在项目报告中记录实际执行的操作及其可检测性标记。客户会很乐意了解其检测系统本应捕获哪些活动。

**默认做法：**默认采用被动方式。仅在以下情况下执行主动探测：(a) 获得明确授权；(b) 在约定的维护时间窗口内；(c) 操作者了解由此产生的日志量。

6.3 验证器规范

当你在野外发现凭据（泄露的 API 密钥、通过 sourcemap 暴露的令牌、公开 Postman 工作区中硬编码的 PMAK）时，可能会想确认其是否仍然有效。此时只能使用只读验证器。

规范：

仅使用只读端点（例如 /me、/whoami、auth.test、sts:GetCallerIdentity）。
绝不使用已验证的凭据创建、修改、删除或发送任何内容。
为验证尝试标记可检测性——每个验证器都会在服务提供方一侧生成审计日志条目。
记录 checked_at（UTC）、响应内容（截断后）以及返回的作用域/账号 ID。
如果操作者的交战规则禁止验证，则将凭据标记为 validation_skipped_by_policy 并停止操作。

具体验证器端点（Postman、AWS、GitHub、Slack、Anthropic、OpenAI、npm、Atlassian、DataDog）见配套的 offensive-osint 技能。

6.4 检测感知探测（检测迹象 + 退避）

探测最终会触发检测。识别这些迹象，并在触发主动响应之前退避。

已被检测到的迹象（严重程度大致递增）：

速率限制响应 — 429 Too Many Requests，设置了 Retry-After 标头，X-RateLimit-Remaining: 0。
验证码中间页 — Cloudflare 中间页、hCaptcha 验证挑战、AWS WAF 页面。
WAF 页面 — 带有服务商品牌标识（Cloudflare、Akamai、Imperva、F5 ASM、AWS WAF、Sucuri）的明确“拒绝访问”页面。
状态码变化 — 之前返回 200/401 的端点现在只对你的 IP 返回 403。
横幅变化 — 服务器标头形式或响应时间持续发生变化。
DNS 污染导致重新变为 NXDOMAIN — 目标的权威服务器不再解析子域名（可能是他们的 CDN 接管了）。
蜜罐诱饵 — 看起来好得不真实的端点（/admin/db_dump.sql、包含无法验证凭据的暴露 .env）。真实暴露很少会如此明显。
直接联系 — 你的马甲邮箱收到“我们发现异常活动”的邮件；或者，在极端情况下，你的 IP 收到友好的滥用举报联系邮件。

退避步骤：

放慢速度。 将并发数减半。请求之间增加 2–10s 的随机抖动。
切换端点。 停止访问触发检测的路径。改用侦察流程中的其他模块。
切换身份特征。 使用新的 User-Agent（在真实浏览器之间轮换），更换 TLS 指纹（使用不同版本的 httpx/curl）。
切换 IP。 更换新的出口（住宅代理、用于敏感查询的 Tor、其他云区域）。
暂停。 等待 1–24 小时。许多 WAF 会按滚动时间窗口评估基于 IP 的信誉；暂停一段时间通常会重置信誉。
记录并咨询。 如果遇到 (3) WAF、(4) 状态变化或 (8) 直接联系，停止主动探测并咨询项目负责人。出现这些信号后继续探测，可能会违反范围约定。

身份特征 / IP 轮换规则：

切勿使用曾在之前的项目中针对同一目标使用过的身份特征。
对于容易被检测的工作，使用住宅代理（Bright Data、Smartproxy、IPRoyal）——但请注意，Cloudflare 有时会屏蔽这些代理的 IP。
Tor 出口节点适用于被动查询（CT 日志、存档网站），但大多数主动探测目标都会屏蔽它们。
云出口 IP（AWS / GCP / Azure）通常会被严格屏蔽，避免用于侦察。请谨慎使用。
记录每次轮换的时间戳和原因；审查人员会询问。

不要：

不要试图通过发送更激进的负载来“智取”已确认的 WAF 屏蔽。这会让客户留下更多日志，也会让你暴露。
不要为了绕过明确的屏蔽列表而切换源 IP——这属于规避行为，可能违反交战规则。
不要因为仪表板显示“仍在运行”就忽略信号。探测过程正在被悄悄记录；后续才会有响应。

7. 外部红队侦察流程

适用于任何经授权的外部评估的 5 阶段流程。各阶段按顺序进行；同一阶段内的模块可以并行运行。

阶段 1 — 种子发现

确认目标的真实情况。

对种子域名执行 WHOIS 查询（注册人、日期、名称服务器）。
枚举 ASN：该组织拥有或使用哪些 AS？（Hurricane Electric BGP Toolkit、RIPEstat、BGPView。）
查询 DNS 记录（A/AAAA/MX/TXT/NS/SOA/CAA）——仅获取记录，暂不遍历。
查询根域名的证书透明度历史记录（crt.sh、Censys）。

阶段 2 — 资产扩展

发现所有可能属于目标的资产。

子域名枚举（优先使用被动数据源：crt.sh、VirusTotal、AlienVault OTX、Shodan，然后进行排列组合和暴力枚举）。
云存储桶枚举（根据公司名称和子域名词干生成 S3/GCS/Azure 组合 — 参见 §15）。
生成仿冒域名（dnstwist 变体 → 解析 → WHOIS）— 同时用于评估钓鱼风险和发现相关企业资产。
使用 Wayback CDX 归档端点查找遗忘的路径。
移动应用发现（Android 使用 google-play-scraper，iOS 使用 iTunes Search API — 参见 §14）。
深度 DNS 遍历（针对配置错误的区域进行 NSEC 遍历，尝试 AXFR）。
枚举 LinkedIn 员工 → 推导电子邮件格式。

阶段 3 — 丰富信息

深入分析已发现的资产。

端口和服务检测（免费使用 Shodan InternetDB → 获得授权后使用 naabu/masscan）。
实时 TLS 握手（证书链、JARM、favicon mmh3 哈希）。
Web 技术检测（通过 httpx 检测约 600 种 Wappalyzer 风格的特征）。
推断 WAF/CDN（根据标头标记）。
如果位于 CDN 后方，查找源站（参见 §27）。
安全标头审计。
批量截图（以可视化方式快速筛查数千台主机）。
从 6 个并行来源收集电子邮件。
电子邮件安全审计（SPF/DMARC/DKIM/BIMI/MTA-STS）。
使用 GitHub 代码搜索 dork 语法（13 个 dork 模板 × 29 种以上的密钥正则表达式）。
深入分析 JavaScript（sourcemap、密钥、端点、内部主机泄露）。
SSO/IdP 租户指纹识别（Entra、Okta、ADFS、Google、SAML、M365 Teams/SharePoint/OAuth — 参见 §11）。
API 和身份验证映射发现（Swagger/OpenAPI、GraphQL、Postman）。
全面搜索 GitHub 之外的密钥（搜索 Postman 公开工作区、Stack Exchange、Trello/Notion/Atlassian dork 语法）。
供应商产品指纹识别（Citrix/F5/PaloAlto/Pulse/Fortinet/Cisco/VMware/Exchange）。
检查容器、CI-CD 和云原生服务暴露情况。
收集招聘信息以推断技术栈。

阶段 4 — 暴露面分析

将资产转化为发现项。

Nuclei（15 项始终启用的内置检查 + 可选二进制文件）。
深度 TLS 审计（sslyze / testssl.sh）。
关联泄露数据与身份信息（HudsonRock Cavalier、HIBP、DeHashed、IntelX、本地语料库 → SSO_EXPOSURE 发现项）。
有针对性地探测配置错误（.git/config、.env、phpinfo.php、/actuator/env、/actuator/heapdump、_cat/indices、/console、/manager/html）。
漏洞优先级排序（CVE × EPSS × CISA KEV × 公开 POC 可用性 — 参见 §28）。

阶段 5 — 报告

让工作成果切实可用。

对每项发现进行风险评分（CVSS + 针对特定项目的权重）。
导出资产关系图（兼容 D3 的节点/链接、GraphML、JSON）。
面向客户的报告（执行摘要 + 技术详情 + 修复建议 — 参见 §31）。
复现包（run_id、工具版本、原始证据、JSONL 日志）。
提交漏洞赏金报告（如适用 — 参见 §30）。

7.5 流水线优先级（按信号密度从高到低）

预算有限时，按以下顺序开展：

凭据泄露 — 信息窃取程序日志（HudsonRock Cavalier 免费套餐）+ HIBP + DeHashed。对红队来说投资回报率最高；通常能获取可用于企业 SSO 的有效明文凭据。需要以邮箱作为输入。
GitHub 侦察 — 代码搜索 dork。可发现 AWS 密钥、Slack 令牌、JWT 密钥、.env 文件。这是最快的云环境横向切入路径。
Nuclei 错误配置扫描 — 暴露的管理面板、带有公开 POC 的 CVE。
云存储桶 — 通过排列组合公司名称和子域名词干进行枚举。可列举的存储桶 = 严重。
端口 — 优先使用 Shodan InternetDB（免费，无需密钥）。VPN 集中器、RDP、Jenkins、GitLab-CE、Elasticsearch 都是高价值的横向切入点。
邮箱 OSINT — 为凭据泄露调查提供线索；为钓鱼名单提供线索。
Web 技术 / WAF / 截图 — 对成千上万个主机进行分类；探测前先了解技术栈。
Wayback — 存档的 JS 通常包含硬编码密钥；存档端点可揭示已移除的管理 / 开发路径。
深度 DNS + 邮件安全 — SPF / DMARC 配置缺失会导致邮件伪造；TXT 验证令牌可揭示 SaaS 租户。
证书 — CT 日志时间线可发现被遗忘的子域名；弱加密套件可轻松形成发现项。
ASN + 反向 DNS — 企业 IP 空间中可能托管未公开的基础设施。
WHOIS — 注册人个人身份信息可揭示相关企业资产。
域名抢注 — 已注册的抢注域名可作为发现项；未注册的域名则列入钓鱼域名候选名单。
安全标头 — 单独来看价值较低，但客户报告中必须包含。

7.6 时间预算与项目配置

阶段和资产数量决定侦察所需时间。以下是粗略估算（单人操作，目标为典型的 SaaS 风格组织）：

阶段	小型组织（<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. 报告	2–4 h	4–8 h	1–2 天

项目配置：

1 小时快速侦察（“X 的暴露情况如何？”） — 阶段 1（15 min）→ 被动子域名枚举（crt.sh + Subfinder，10 min）→ 对已解析的 IP 使用 Shodan InternetDB（5 min）→ 通过 Hunter+IntelX 收集邮箱（10 min）→ 查询邮箱是否泄露（10 min）→ 仅输出执行摘要（10 min）。
4 小时重点侦察（“钓鱼准备度检查”） — 增加：完整邮箱收集、LinkedIn 员工枚举、SPF / DMARC 分析、域名抢注候选项生成、SSO / IdP 指纹识别。输出：钓鱼可行性报告 + 目标邮箱名单。
1 天标准侦察 — 按上述优先级完成阶段 1–4。输出：逐项资产发现清单 + 资产图谱 + 执行摘要。
1 周深度侦察 — 完成标准侦察的全部内容，另加：深度模式用户枚举、按完整预算进行 JS 深度分析、移动端攻击面、云原生指纹识别、供应商产品指纹识别、软件包注册表泄露搜寻、漏洞优先级排序。输出：完整的客户交付包 + 复现材料包。
持续监控（每周差异对比） — 每周重新运行阶段 1–3；与基线进行差异对比；发现新资产 / 新发现项 / 资产消失时发出警报。

提前终止的情况：

阶段 1 后，如果范围有误（目标最终被确认是无关企业的子公司；需要澄清交战规则）。
阶段 2 后，如果攻击面低于阈值（没有公开 Web 应用 + 没有暴露服务 + 没有泄露邮箱 → 从外部几乎无从发现）。
任何阶段中，如果出现 §6.4 所述的 WAF / 检测迹象。

8. 资产图谱规范

将每项发现都视为图谱中的类型化资产，而不是孤立的字符串。

8.1 资产分类（29 种类型）

类别	资产类型
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`

8.2 资产架构

每项资产都包含：

type — 上述 29 种类型之一。
key — 唯一的去重 ID（带类型前缀，例如 sub:api.example.com、email:[email protected]）。
value — 实际字符串或对象。
sources[] — 确认此资产的所有来源（已去重）。
confidence — TENTATIVE / FIRM / CONFIRMED。
first_seen、last_seen — UTC 时间戳。
attrs{} — 特定类型的元数据（例如，对于 webapp：status_code、title、tech-stack 列表、JARM、favicon mmh3、截图路径）。

8.3 关系分类

关系使用类型化边表示，而非文本： RESOLVES_TO、HOSTED_ON、IN_NETBLOCK、BELONGS_TO_ASN、LISTED_IN_CERT、OWNED_BY、ALIAS_OF、BREACHED_FROM、EMPLOYED_BY、HOSTS_REPO、TYPOSQUAT_OF、EXPOSES、DOCUMENTED_BY、BELONGS_TO_HOST、REQUIRES_AUTH、LEAKS_SCHEMA、SHIPPED_BY_ORG、CONTAINS_SECRET、TALKS_TO_HOST、EXPOSES_DEEPLINK、HAS_EXPORTED_COMPONENT、USES_FIREBASE_PROJECT、LACKS_PINNING_FOR。

8.4 规范规则

每项发现都是一项资产。 不要针对孤立字符串记录发现；先创建资产，再关联发现。
按 key 去重，而非按 value 去重。 相同的值、不同的类型 ≠ 同一项资产（sub:api.example.com 和 webapp:https://api.example.com/ 是不同资产，两者之间有一条 BELONGS_TO_HOST 边）。
来源信息不可或缺。 sources[] 必须列出所有来源。如果有两个来源确认了该资产，就都要列入。
置信度按来源确定，再进行汇总。 某子域名被 3 个被动来源返回，置信度为 FIRM；只被仅提供摘要片段的 Bing 返回，置信度为 TENTATIVE。
通过旁路文件延迟绑定。 当模块 A 生成模块 B 所需的输出时，写入 JSON 旁路文件（mobile_endpoints.json、secrets_sidecar.json），不要让模块 B 等待模块 A。参见 §24。

8.5 资产级分诊规则

当你手头有各种类型的资产，但探测预算有限时，应按每项资产能带来的价值确定优先级：

按主机名信号排列 WebApp 优先级（从高到低）：

与身份验证相关的主机名（auth.、login.、sso.、idp.、accounts.、oauth.）。
管理路径（/admin、/dashboard、/console、/manager、/wp-admin、/phpmyadmin）。
开发／预发布主机（dev.、staging.、stg.、qa.、uat.、test.、sandbox.、preprod.、preview.）——防护较弱，且经常会暴露生产数据。
API 主机名（api.、services.、gateway.、graph.）。
面向客户的主机名（portal.、app.、my.、account.）。
营销／内容主机名（www.、blog.、news.、careers.、support.）。

按推断的功能排列子域名优先级：

API > 管理 > 开发 > 身份验证 > 生产应用 > 营销。

按网段排列 IP 优先级：

企业 ASN 所有者（最有可能托管未公开的内部基础设施）。
云网段（AWS / GCP / Azure / DO / OVH）——变动频繁，但值得关注云原生服务。
CDN 网段（Cloudflare / Akamai / Fastly）——通常是边缘节点，而非源站；除非要发现源站，否则应延后处理。

按角色提示排列电子邮件优先级：

角色标识	优先级	原因
`ceo@`、`cfo@`、`cto@`、`ciso@`	最高	高管账户的泄露价值最高（商务邮件入侵、财务权限、董事会访问权限）。
`it@`、`helpdesk@`、`support@`、`security@`	高	IT／安全账户可访问高权限工具；帮助台账户会处理重置工作流。
`dev`、`engineer`、`architect`、`dba`	中	开发者账户通常可访问 GitHub / 云服务 / CI。
`sales`、`marketing`、`hr`、`finance`	中	可访问 SaaS（Salesforce、HubSpot、Workday）；财务权限可能导致商务邮件入侵。
通用角色账户（`info@`、`noreply@`、`contact@`）	低	通常无人监控，或只是转发别名；个人背景信息较少。

按近期活动和命名排列仓库优先级：

最近推送过（过去 30 天内）> 长期未更新。
描述中包含目标名称的公开仓库 > 仅代码中包含目标名称的仓库。
从看起来像内部仓库的上游仓库分叉而来的仓库 > 独立仓库。
名称中包含 prod、internal、private、secret → 即使是公开仓库，优先级也为高（可能命名不当或意外暴露）。

**执行顺序：**当你有 N 项资产，而预算只够进行 M 次探测（M < N）时，先按资产类型确定优先级，再按类型内的优先级排序。例如：有 50 个子域名 → 先探测 API、管理和开发子域名（约 15 个），再探测身份验证和生产应用子域名（约 20 个），将营销／内容类子域名留待后续处理。

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

严重性取决于实际影响，而非主观判断。请参照以下标准：

9.1 严重

未经身份验证即可执行代码、已确认有效的凭据、可列出生产数据、根本性的信任违规。

示例：

生产 WebApp 暴露 .git/config（完整源代码泄露）。
暴露 /.env（凭据以明文形式存储，通常包括数据库／云服务／API 凭据）。
无需身份验证即可访问 Spring Boot /actuator/env 或 /actuator/heapdump。
可列出且包含用户数据的 S3 / GCS / Azure 存储桶。
未经身份验证即可向会修改状态的写入端点发送 POST/PUT/DELETE 请求。
Firebase Realtime Database 未设防（https://{project}.firebaseio.com/.json 可返回数据）。
生产 Android 应用中设置了 android:debuggable=true。
经实时验证且权限范围广的凭据（PMAK、AWS 密钥、Anthropic/OpenAI 密钥）。
泄露数据集中有 ≥10 名员工的信息，且已识别其租户（SSO_EXPOSURE）。
Elasticsearch 集群未设防（/_cat/indices 可返回数据）。
Docker API 未设防（/v1.40/containers/json 可返回容器信息）。
Redis 未设防（无需 AUTH；可写入 authorized_keys）。
Kubernetes API 服务器未设防且启用了匿名身份验证。
kubelet 在 10250 端口开放（无需身份验证即可执行 Pod 命令）。
etcd 在 2379 端口开放（可访问集群状态和密钥）。
RDP 存在 BlueKeep 漏洞、SMB 存在 EternalBlue 漏洞。
存在特定版本的 Citrix Netscaler / F5 BIG-IP RCE CVE。

9.2 HIGH

存在重大暴露，但尚未达到 RCE；有明确的升级路径；泄露高价值信息。

示例：

GitHub 仓库中公开的密钥（PAT、AWS 密钥、Slack 令牌等）。
可访问源映射文件（.js.map）——完整泄露前端原始源代码。
生产环境开放 GraphQL 内省（完整架构泄露 → 可枚举变更）。
可能发生子域名接管（CNAME 指向未认领的 Heroku/Shopify 等）。
反射式 CORS 且允许凭据（Access-Control-Allow-Origin: <reflected> + Access-Control-Allow-Credentials: true）。
HTTP 方法篡改：某个端点隐藏支持 DELETE/PATCH，但公开只允许 GET。
敏感路径（/login、/sso、/admin、/auth）缺少 HSTS——从 MED 升级。
暴露 Jenkins/Tomcat-Manager/phpMyAdmin 管理界面（无身份验证或使用默认凭据）。
可连接 Telnet（端口 23）。
移动应用中的 WebView 带有 JS 桥接接口（存在 XSS → RCE 的可能）。
移动应用中存在敏感的深层链接处理程序。
生产发信域名的 DMARC 策略为 p=none（可进行欺骗）。
厂商产品横幅显示存在已知且尚未修补的 CVE（已列入 KEV）。

9.3 MEDIUM

信息泄露、加固不足、易受暴力破解。

示例：

标准页面缺少安全标头：HSTS、CSP。
Apache /server-status 或 /server-info 可访问。
仅在开发/预发布环境中可访问 phpinfo() 或 /info.php。
JS 中泄露内部 IP、主机名或 K8s 服务 DNS。
错误页面泄露架构信息（堆栈跟踪、ORM 特征）。
Android 应用中设置了 android:allowBackup=true。
Android 应用中设置了 android:usesCleartextTraffic=true。
导出的 activity/service 未使用 android:permission 保护。
API 端点缺少速率限制。
返回与用户相关数据的 API 使用通配符 CORS（Access-Control-Allow-Origin: *，不允许凭据）。
Slack webhook URL 泄露。
Twilio Account SID 泄露（未泄露身份验证令牌）。
SPF 记录过于宽松（+all 或包含过多记录）。

9.4 LOW

外观层面或影响较小的加固不足。

示例：

缺少 X-Frame-Options。
缺少 X-Content-Type-Options。
暴露 .DS_Store。
Stripe 测试密钥泄露。
Firebase URL 暴露（仅 URL，没有开放的 RTDB）。
移动应用缺少证书固定。
检测到过时的 WordPress 安装（尚无已知漏洞）。
未配置 BIMI（仅存在品牌冒充风险）。

9.5 INFO

值得记录，但无需立即采取行动。

示例：

缺少 Referrer-Policy / Permissions-Policy。
发现 /.well-known/security.txt。
robots.txt 暴露了值得关注的路径。
存在私有存储桶，但访问受到限制。
在泄露数据语料库中检测到该域名，但涉及的员工账户为 0 个。
未启用 DNSSEC。

9.6 严重性升级规则

身份验证/登录/SSO/管理路径缺少 HSTS → MED → HIGH。
通配符 CORS + 凭据 → MED → HIGH。
通配符 CORS + 敏感端点 → LOW → MED。
兴趣评分标准（配套技能 §20）得分 ≥70 的 API 端点 → 至少 HIGH。
域名泄露事件涉及 ≥10 名员工 → 无论数据是否过时，均为 CRITICAL。
厂商产品版本与 CISA KEV 条目匹配 → CRITICAL。
DMARC 为 p=reject + 严格 SPF + 已轮换 DKIM → 不升级；安全态势良好。

10. 漏洞赏金 / 红队切换模式

现有调查工作（威胁行为者研究、人肉搜索调查、归因分析）与进攻性侦察采用不同的工作方式。请明确切换工作方式。

方面	调查模式	进攻性侦察模式
探测频率	缓慢、单线程，并融入正常流量。	短时间突发并行探测，但针对每个服务提供商限制频率。
OpSec 工作方式	仅使用马甲账号，绝不透露调查人员身份。	使用的角色可以是本次测试中的角色；团队可能会通知 SOC。
证据处理	符合法庭标准的证据保管链；记录哈希值、时间戳和屏幕截图。	符合测试标准；同样严格记录哈希值和时间戳，但证据用于客户报告。
范围内的严重性	所有严重性级别都与背景相关。	CRIT/HIGH/MED 级别很重要；LOW/INFO 级别通常不会列入执行摘要。
授权工作方式	仅使用公开记录 / OSINT；未经授权不得探测私有资源。	书面交战规则；明确测试范围；明确范围外事项清单。
报告格式	叙述性内容 + 带来源的时间线。	按资产列出发现 + 修复建议 + 复现步骤。
停止条件	问题得到解答时。	测试窗口结束或报告交付时。

与用户合作时，如果无法从上下文判断其所处模式，请询问他们。

10.1 基于规模的策略

组织规模会影响哪些技术最有效。

小型组织（< 100 名员工）：

高管账号的影响远超其他账号；攻陷一名 CEO/CFO 往往就能掌控一切。
邮箱数量较少，可以彻底枚举（总计 10–50 个邮箱）。
可能使用 Microsoft 365 或 Google Workspace；身份体系集中在一个租户中。
代码仓库通常以个人账号名义公开托管在 GitHub 上（创始人从个人开发转型而来）。
云服务通常只有一个 AWS 账号或 GCP 项目。
策略：深入调查每个邮箱和每项身份体系发现；完整枚举 LinkedIn；检查创始人的个人 GitHub 组织。

中型组织（100–1K）：

均衡枚举。邮箱列表可以枚举，但无法做到穷尽。
身份体系可能只有一个 IdP，但使用多个 SaaS 租户（Slack 工作区、Notion 组织、GitHub 组织）。
可能有移动应用；检查两个应用商店。
云服务可能采用多账号或多区域架构。
策略：以标准深度执行完整流程；对每类资产进行抽样后深入调查；按角色确定 LinkedIn 优先级。

大型组织（1K–10K）：

邮箱枚举会有所遗漏（抽样检查重要职位）；数据泄露影响规模扩大。
采用多租户身份体系（通常包括 Entra、Okta 和多个 Auth0 客户租户）。
有移动应用，且不同团队可能发布多个 Android 包。
云服务架构庞大；子公司 / 并购会使范围更加复杂。
策略：优先广度；依靠自动化发现资产；手动分流调查发现。

超大型组织（10K+）或集团：

首先绘制品牌切换关系图：枚举每个品牌域名和每家子公司。
数据泄露语料占主导地位：员工人数超过 10K 意味着过去发生过大规模数据泄露的可能性很高。
不同业务部门的身份体系可能各不相同（受法律实体边界影响）。
策略：范围缩减是最重要的一步；全程结合抽样与自动化；仅深入调查高优先级发现。

**跨规模原则：**组织越小，关注单个账号越有价值。组织越大，系统性安全态势发现（DMARC 配置缺失、SSO_EXPOSURE 覆盖面、供应商产品版本扫描）的价值越高。

11. 身份体系映射

组织的 IdP/SSO 安全态势是高价值目标：攻陷身份体系后，就不必逐个攻破应用。请有条理地进行映射。

11.1 子域名前缀枚举

针对目标的根域名（以及发现的任何同级品牌域名）探测以下前缀：

auth.{domain}
login.{domain}
sso.{domain}
idp.{domain}
iam.{domain}
identity.{domain}
accounts.{domain}
oauth.{domain}

并对每个可访问的子域名执行通用 OIDC 发现：

{any-host}/.well-known/openid-configuration

11.2 Microsoft Entra (Azure AD)

OIDC 元数据 + 租户 GUID 提取 — 获取 https://login.microsoftonline.com/{tenant-or-domain}/.well-known/openid-configuration。issuer 字段会返回包含租户 GUID 的 URL（8-4-4-4-12 位十六进制格式）。租户 GUID + 域名 = 稳定的租户指纹。
getuserrealm.srf — https://login.microsoftonline.com/getuserrealm.srf?login=<user>@<domain> 会返回 NameSpaceType：Managed（云原生）、Federated（本地 ADFS / 外部 IdP）或 Unknown。可检测性：低。
Autodiscover v2 — 向 https://autodiscover-s.outlook.com/autodiscover/metadata/json/1 发送包含电子邮件地址的 POST 请求；检测租户成员身份。
GetCredentialType（深度模式用户枚举）— 向 https://login.microsoftonline.com/common/GetCredentialType 发送 POST 请求 {"username": "<email>"}。响应会表明该电子邮件地址是否存在于租户中。可检测性：中。每个租户最多尝试 20 次。

11.3 Okta

组织 slug 推导 — 根据子域名 + 根域名主体推导候选 slug；Okta 租户位于 <slug>.okta.com（或 <slug>.oktapreview.com）。
OIDC 指纹 — https://<slug>.okta.com/.well-known/openid-configuration。
/api/v1/authn 用户枚举（深度模式）— 发送 POST 请求 {"username": "<email>", "password": "invalid"}。400 与 401 响应代码可表明用户是否存在。可检测性：中。每个租户最多尝试 20 次。

11.4 ADFS

被动指纹识别 — GET https://{domain}/adfs/idpinitiatedsignon.aspx → 返回 200 表示存在 ADFS。
主动 mex 端点（深度模式）— https://{domain}/adfs/Services/Trust/mex 返回 SOAP 元数据。

11.5 Google Workspace

https://{domain}/.well-known/openid-configuration — 由 Google 托管的域名客户会公开具有特征性 issuer/JWKS URI 的发现端点。
指向 *.googlemail.com / aspmx.l.google.com 的 MX 记录是 Google Workspace 的强烈信号。

11.6 通用 OIDC（Keycloak / Auth0 / Ping / OneLogin / Duo）

探测每个存活子域名的 /.well-known/openid-configuration。
issuer 和 authorization_endpoint 字段可用于识别 IdP 产品。
*.auth0.com、*.onelogin.com、*.pingone.com、*.duosecurity.com 等模式具有特征性。

11.7 SAML 元数据

探测每个存活 Web 应用的以下路径：

/saml/metadata
/FederationMetadata/2007-06/FederationMetadata.xml
/federationmetadata/2007-06/federationmetadata.xml
/simplesaml/saml2/idp/metadata.php
/auth/saml2/metadata

SAML 元数据 XML 包含：EntityID、签名证书、SingleSignOnService URL、NameIDFormat。

11.8 AWS 账户 ID 提取

S3 存储桶区域响应头 — 对已知目标存储桶执行 HEAD 请求会返回 x-amz-bucket-region；结合存储桶名称的随机性推断账户。
JSON / HTML 响应中的 ARN 正则表达式 — 搜索 arn:aws:[a-z0-9-]+:[a-z0-9-]*:([0-9]{12}):（12 位 AWS 账户 ID 是捕获组）。
JS / API 响应中的 AccountId 属性 — 常见于 IAM 相关错误消息和 CloudFormation 输出。
OAuth client_id 泄露 — Google OAuth：<digits>-<chars>.apps.googleusercontent.com；MSAL：clientId 属性中的 GUID。

11.9 输出

每个发现的 IdP 都会成为一个带有 attrs.product、attrs.tenant_id、attrs.discovery_endpoint 的 Service 资产。然后在第 4 阶段与泄露数据进行关联：已发现租户下的每个遭入侵用户都会成为一个 SSO_EXPOSURE 发现项（严重 — 参见 §22.3）。

11.10 Microsoft 365 深度攻击面

除了基础的 Entra 指纹识别，M365 还暴露了更广泛的攻击面，值得深入枚举。

Teams 联合：

https://login.microsoftonline.com/<target-domain>/.well-known/openid-configuration 可确认租户。
Teams 联合状态：https://teams.microsoft.com/api/mt/<region>/beta/users/<email>/externalsearchv3（需要来自联合租户的已认证请求；可用于确认是否允许外部 Teams 聊天）。
已启用外部聊天 = 软攻击面（通过 Teams 聊天进行语音钓鱼、短信钓鱼，以及冒充 IT 的借口）。
开放联合（任何租户都可以聊天）是默认设置；检查目标是否对此进行了限制。

SharePoint 子域名：

<target-stem>.sharepoint.com — 主租户的 SharePoint。
<target-stem>-my.sharepoint.com — OneDrive for Business URL（每位用户的个人站点）。
<target-stem>-admin.sharepoint.com — SharePoint 管理中心（需要身份验证，但其存在可确认租户）。
<target-stem> 根据公司名称推导（通常是 .com 前面的部分）。

OneDrive 个人站点枚举：

每位用户的 OneDrive URL：https://<target-stem>-my.sharepoint.com/personal/<user_email_with_underscore>/Documents/。
在电子邮件地址中将 @ 和 . 替换为 _（例如，[email protected] → alice_acme_com）。
已认证探测；可用于确认是否已预配 OneDrive 个人站点（这本身就是一个存在性指标）。

M365 OAuth client_id 发现：

许多内部应用会在 Entra 中注册 OAuth client_id。在 JS 包、移动应用字符串和 API 响应中搜索 client_id=<GUID> 模式。
Microsoft 已公开记录 Office、Graph 等产品的知名第一方 client_id；发现非 Microsoft GUID 可揭示自定义内部应用。
端点 https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration 会列出支持的端点；有些租户会启用 device_authorization_endpoint（设备代码钓鱼目标）。

Power Platform / Power Apps：

https://make.powerapps.com/environments（需要身份验证）；环境 ID 有时会泄露在 URL 中。
*.crm.dynamics.com（Dynamics 365 / Power Apps 默认 URL）。
*.azurewebsites.net 用于 App Service 部署。

需留意的 M365 OAuth 错误配置发现：

common 租户启用了 device_authorization_endpoint（设备代码钓鱼目标）→ 中等（存在运营风险；无法直接利用，但会助长攻击）。
自定义 OAuth 应用启用了 Public client 流程并具有宽泛的范围（offline_access、Mail.Read、Files.Read.All）→ 高，前提是该应用已获租户批准。
由目标发布的多租户 OAuth 应用（其他租户可以授予同意）→ 检查范围是否包含敏感的 Graph 权限。

**可检测性：**所有 M365 端点探测都会记录到 Entra 登录日志 / 审计日志中（仅获取请求时为中低；任何身份验证尝试时为中）。

12. API 与身份验证映射方法

现代目标会暴露 REST、GraphQL 和未公开的内部 API。OSINT 的目标是枚举这些 API、进行分类，并按攻击价值排序。

12.1 发现路径

Swagger / OpenAPI — 在每个存活的 Web 应用上探测 28 个路径的词表（配套技能 §16.1）。解析 YAML/JSON；提取每个端点（方法 + 路径）。
GraphQL — 探测 13 个路径的词表（配套技能 §16.2）。发送标准内省查询的 POST 请求。如果返回架构，即可获得完整的类型、查询、变更和订阅枚举。
禁用内省时的 GraphQL — 回退到字段建议枚举（配套技能 §22.9）。
Postman — 使用目标名称查询 Postman 的公开通用搜索端点；遍历每个匹配的工作区；提取请求、标头、预请求脚本、测试脚本和环境变量。
从 JS 提取的端点 — 从 JavaScript 包中提取的每个端点都会送入同一分类器。
从移动应用提取的端点 — 从 APK 静态分析中提取的每个端点都会通过 sidecar（mobile_endpoints.json）送入。

12.2 分类

对每个端点，记录：

url, method, source[], auth_required, auth_type, auth_location,
rate_limited, cors_policy, sensitive_path_keywords[], schema_leaks,
verb_tampering_possible, interest_score (0..100), interest_reasons[]

各字段的判定方法：

发送 OPTIONS → Allow 标头会显示受支持的方法（动词篡改检查）。
不带身份验证发送 GET → 200 = auth_required=false；401/403 = auth_required=true。
捕获响应标头中的 WWW-Authenticate（auth_type）、RateLimit-* / X-RateLimit-*。
发送带有 Origin: https://attacker.example 的请求 → 如果响应中的 Access-Control-Allow-Origin 反射了该值，则为 cors_policy=reflected。
触发错误 → 检查响应中是否包含堆栈跟踪、ORM 提示。

12.3 关注度评分（0–100）

完整评分标准见配套技能 §20。评分 ≥ 70 → 判定为 HIGH/CRITICAL 发现，并在证据中加入 attack_path_hint。

12.4 攻击路径提示

生成 HIGH/CRITICAL 发现时，在证据中加入一句攻击路径提示，让操作人员知道从何处开始利用。模板见配套技能 §39。

13. JavaScript 深度分析

对每个存活的 Web 应用抓取其 JS——现代前端会在其中泄露信息。

13.1 脚本发现

解析 HTML 中的 <script src="..."> 和 <link rel="modulepreload" href="...">。
针对常见打包工具，探测猜测路径列表（配套技能 §16.9）。

13.2 Sourcemap 检测（高危信息泄露）

内联引用：在包末尾匹配正则 //[#@]\s*sourceMappingURL=。
同级文件抓取：尝试获取每个已发现 JS 旁边的 <bundle>.map。
如果可访问：解析 sourcemap 的 sources[]（会泄露仓库结构）和 sourcesContent[]（内嵌完整原始源代码）。对 sourcesContent[] 运行机密信息目录扫描。
严重性：HIGH INFO_DISCLOSURE。

13.3 机密信息扫描

对每个 JS 正文和每个已解析的 sourcesContent[] 块运行 29+ 模式目录扫描。每次命中 = 一条 SECRET_LEAK 发现，严重性按目录中对应模式的定义。

13.4 端点提取

使用三个正则层级（配套技能 §16.10）。每个唯一端点都会成为 wayback_endpoint 资产，并送入 §12 中的 API 分类器。

13.5 内部主机泄露检测

使用三种模式（配套技能 §16.11）：RFC1918、内部 DNS 后缀、K8s 服务 DNS。每次匹配 = MEDIUM INFO_DISCLOSURE。

13.6 GraphQL 内省探测

当提取的端点以 /graphql 或 /graphiql 结尾时，发送标准内省查询的 POST 请求。如果返回架构 → HIGH MISCONFIG。随后枚举变更和订阅，寻找高价值目标。

13.7 Next.js 清单解析

_buildManifest.js 和 _ssgManifest.js 会枚举每个 Next.js 页面路由，从而暴露应用程序的完整路由结构。

13.8 预算指南

每次任务分析的 Web 应用上限：默认 40 个，使用 --deep 时为 120 个。
每个 Web 应用的 JS 文件上限：默认 40 个，使用 --deep 时为 80 个。
单个 JS 文件大小上限：2 MiB。
单文件超时：10 秒。

14. 移动端攻击面

移动应用往往是最薄弱的环节。

14.1 应用发现

Android — google-play-scraper。按公司名称、品牌关键词、根域名词干搜索。
iOS — iTunes Search API。

14.2 所有权置信度（0–100）

参见配套技能 §21。深度分析的阈值：≥70。

14.3 APK 获取与静态分析

通过 APKPure HTML 抓取下载。
使用 zipfile 和可选的 androguard 提取。
提取：AndroidManifest.xml、资源字符串、资源文件、原生 .so 文件、classes*.dex（字符串提取）。

14.4 秘密扫描

对清单、资源、资源文件和 dex 字符串提取结果运行目录扫描。

14.5 后端主机名提取

每个发现的主机名都会成为一个 subdomain 资产。写入旁路文件 mobile_endpoints.json，供 API 发现模块使用。

14.6 清单配置错误发现

清单属性	严重级别
`android:debuggable="true"`	严重
`android:allowBackup="true"`（未设置白名单）	中
`android:usesCleartextTraffic="true"`	中
未设置 `android:permission` 的导出活动/服务/接收器	中
敏感深层链接处理程序	高
使用 `setJavaScriptEnabled(true)` + `addJavascriptInterface(...)` 的 WebView	高
未启用证书固定	低

14.7 Firebase 标准探测

针对提取到的每个 Firebase 项目 ID：

Realtime DB — GET https://{project-id}.firebaseio.com/.json。返回 JSON 树 → 严重 OPEN_FIREBASE_RTDB。
Firestore — https://{project-id}.firebaseapp.com/。
Storage — 对应的 GCS 存储桶。
Remote Config — 只有提取到 API 密钥和应用 ID 后才能读取。

14.8 iOS 路径

仅通过 iTunes Search API 发现。
ITMS 链接提取：https://apps.apple.com/<region>/app/<slug>/id<bundle-id>。
隐私营养标签（App Store Connect）：公开发布，可用于了解应用会接触哪些数据。
不建议自动下载（需考虑 DMCA / DRM）。

15. 云攻击面

15.1 存储桶排列

根据目标的根域名、子域名前缀，以及可选的品牌/公司名称构建候选存储桶名称。除非通用前缀与可识别目标的标记组合使用，否则应过滤掉这些前缀。应用 6 个前缀 × 15 个后缀（配套技能 §16.8 中列出了这些内容）。

15.2 提供商 URL 模板

S3、GCS、Azure Blob 模板——参见配套技能 §16.8。

15.3 探测技术

先发出 HEAD 请求。状态码 200/301 = 存在；403 = 存在，但为私有；404 = 跳过。
如果存在，对存储桶根目录发出 GET 请求。可列出的 XML/JSON 列表 → 严重。

15.4 严重级别映射

结果	严重级别
存储桶可列出	严重
存储桶存在，对象可通过直接 URL 读取但不可列出	高
存储桶存在，ACL 为私有	信息

15.5 相邻云信号

从 S3 区域/错误响应中提取 AWS 账户 ID。从 GCS 错误响应中提取 GCP 项目 ID。从 Blob URL 格式中提取 Azure 租户 ID。

16. 加密货币调查

16.1 交易分析

跟踪钱包之间的资金流；识别相关地址集群；监控大额转账。

工具：Cielo（多链）、TRM（图谱）、Arkham（多链 + 实体标签）、MetaSleuth（可视化）、Range（CCTP）、Socketscan（EVM 桥）、Pulsy（桥聚合器）、Chainalysis Horizon 2.0（付费）、Elliptic Lens。

16.2 Layer 2 / Rollup 分析

zkSync Era / Polygon zkEVM — ZK 证明隐藏 L2 详情；只能看到 L1 桥事件。
Arbitrum / Optimism — 批量处理/压缩；从 L1 calldata 获取 L2 状态。
StarkNet — Cairo VM；地址推导方式不同。
Base / Blast / Scroll — OP Stack 或 ZK。
L2 上的隐私协议 — Aztec（可编程隐私）、Railgun（屏蔽池）、Privacy Pools（Tornado Cash 的后继协议）。

方法： 从 L1 桥事件入手；使用 L2 浏览器查看 Rollup 内的活动；对于隐私协议，重点进行时间分析和聚类。

16.3 注意事项

桥会引入铸造/销毁语义；避免假设资金流为 1:1。
MEV/聚合器路径会制造虚假的“直接”踪迹。
L2 最终确定性：乐观 Rollup 有 7 天的挑战期。

16.4 钱包 / 交易所 / NFT 画像分析

相同的模式：年龄 + 活跃度 + 关联关系 + 随时间变化的余额 + 关联账户。NFT 还需查看所有权历史、元数据和关联钱包。

17. 图像分析

17.1 反向图像搜索

Google 图片 / Lens（Lens 可能需要身份验证——使用傀儡账号的无痕模式）。
Yandex 图片（对俄语 / 东欧内容效果最佳）。
Bing 图像匹配、TinEye、Copyseeker、Perplexity Pro。
浏览器扩展：RevEye、Search by Image（多引擎）。
用 Picarta 进行 AI 地理定位。

17.2 元数据（EXIF）

ExifTool、Jeffrey's Image Metadata Viewer、EXIF Viewer Pro。

17.3 图像取证

Forensically、FotoForensics、Bellingcat Photo Checker、Sensity AI、Exposing.ai、Adobe Content Credentials Verify、c2patool。技术包括：ELA、元数据、克隆检测、噪声分析。

17.4 地理定位工作流

前景——标志、车牌、服装、植被、天气。
背景——地标、独特建筑、山脉、水域、基础设施。
地图标记——动植物、季节性指标。
反复尝试——Google Street View、Bing Streetside、Yandex Panorama。
使用 Overpass Turbo 查询 OpenStreetMap。
山峰识别——PeakVisor、Peakfinder、PeakLens AR。
OCR——Google 或 Yandex OCR。
视频文字稿——YouTube 字幕可优化关键词搜索。

17.5 专用工具

火灾识别——NASA FIRMS、Sentinel Hub、Global Forest Watch、Copernicus EFFIS。
飞机追踪——Apollo Hunter、FlightRadar、ADS-B Exchange。

18. 视频分析

18.1 提取上下文

标志 / 横幅、建筑风格、道路标线、车牌、服装、跨平台片段搜索。

18.2 元数据

YouTube Data Viewer（Amnesty）、使用 ExifTool 分析下载的文件。

18.3 平台专用

TikTok / Instagram——API 经常变化；优先使用平台导出；按 1–4 小时的间隔抽样。
Bluesky AT Protocol——通过 bsky.social/xrpc/com.atproto.identity.resolveHandle 解析 DID；通过 plc.directory/<did> 获取身份文档；在 Firesky 使用 firehose；使用 SkyView 查看关系图。尽早存档——账号名迁移 / 帖子删除。
Mastodon / Fediverse——实例很重要（司法管辖区、日志记录）；使用 WebFinger 发现内容；使用 FediSearch 跨实例搜索；通过 Fediverse Observer 枚举实例；ActivityPub 对象采用 JSON-LD 格式。
Threads——存在与 IG-API 类似的限制。

18.4 听觉线索

语言、方言、背景噪声（火车汽笛、祈祷声、野生动物）。工具：Audacity、Sonic Visualiser、SoundCMD。使用频谱图寻找独特模式；使用 Shazam / SoundHound 识别音乐。

18.5 帧提取

FFmpeg、VLC。拼接全景图；稳定平移镜头（使用 FFmpeg deshake 或 Blender VSE）。优先使用原始上传内容，而非重新编码的版本。

19. 时间定位与时间分析

19.1 阴影分析

工具：SunCalc、ShadeMap、Bellingcat Shadow-Finder、NOAA Solar Calculator。

19.2 天文计算

使用 Stellarium、SkyMap、MoonCalc 模拟不同时间 / 地点的天空。

19.3 卫星图像时间

Google Earth Pro（历史图像滑块）、Sentinel Hub EO Browser（使用 Sentinel + Landsat 影像进行延时浏览）。以 WKT 格式记录坐标；对缓存的瓦片集计算哈希。

20. 威胁行为者调查

20.1 以攻击者为中心的工作流

范围界定 — 提出攻击者假设（APT28/29、Turla、Sandworm；APT10/41、Mustang Panda、Volt Typhoon）。从 CERT 和供应商收集初始报告。
指标收集 — 收集 IOC（域名、IP、哈希、JA3/JA4、用户代理）。通过被动 DNS、CT 日志、沙箱提交记录进行验证。
基础设施映射 — 从 CT 日志（SAN、颁发者、序列号）、共享主机、NS 重用、注册商账户、HTML 指纹入手进行关联分析。结合 ASN/WHOIS 历史记录、RPKI/ROA、地理位置丰富信息。
样本分析 — 分析 PE/ELF 元数据（PDB 路径、编译时间戳、Rich 标头、代码签名）。使用 SSDEEP/TLSH 进行聚类；查找 YARA 匹配项。
社交 / 采购关联分析 — 开发者账号、代码片段、学术论文、招聘信息、采购记录。
证伪与报告 — 权衡每项关联；记录其他可能解释；将 TTP 映射到 MITRE ATT&CK；注明来源章节和页码。

20.2 归因准则

将能力与意图、赞助分别考量。
三项准则：3 项弱证据，或 1 项强证据 + 1 项弱证据。
优先采用持久的关联线索（注册商账户、代码签名证书、构建路径惯用写法），而非短暂线索（解析出的 IP）。
标明不确定性级别；区分相关性与控制关系。

20.3 俄罗斯特有的关联线索

企业 / 人员 — EGRUL/EGRIP（需通过验证码）、Rusprofile、Kontur.Focus、zakupki.gov.ru、hh.ru。
基础设施 — 通过 whois.tcinet.ru 查询 RU WHOIS；在 Telegram 上查找频道、管理员和交叉发布内容。
媒体 — VKontakte、Odnoklassniki、Rutube；使用俄语及其转写形式搜索。

20.4 中国特有的关联线索

企业 / 人员 — gsxt.gov.cn（国家企业信用信息）；天眼查 / 企查查；在 beian.miit.gov.cn 查询 ICP 备案 → 关联 USCC。
基础设施 — CNNIC WHOIS；常见的国内云服务（Aliyun、Tencent、Huawei）。
媒体 — Weibo、WeChat（通过 weixin.sogou.com）、Zhihu、Bilibili、Douyin、Xiaohongshu；使用中文 + 拼音。

20.5 基础设施与互联网测量

IP→ASN（HE BGP Toolkit、RIPEstat、BGPView）。
通过 CT 日志（crt.sh）查找证书重用和签发频率；根据主体 / 颁发者 / 序列号进行关联分析。
使用 URLScan 检查 HTML 指纹、网站图标（mmh3）、脚本哈希。
使用 DNS 时序数据（SecurityTrails PDNS、DNSDB）查找子域名变更和暂存域名。

21. 人员与社交媒体调查

21.1 用户名枚举

WhatsMyName、NameCheckup、Sherlock、Maigret。

21.2 头像与人脸搜索

PimEyes、Exposing.ai、Azure Face API（合规）。

21.3 社交关系图谱与内容分析

Maltego、snscrape、SocialBlade。Bluesky / Mastodon：实例浏览器 + 账号解析器。

22. 泄露数据 × 身份关联

这是外部红队演练中单项投资回报率最高的技术。每次演练都要执行。

22.1 数据源组合

来源	层级	备注
Hudson Rock Cavalier	免费	信息窃取程序日志数据集；对企业 SSO 的信号价值极高。
Have I Been Pwned	免费 + 付费	查询整个域名是否存在泄露记录 + Pwned Passwords（k-匿名性）。
DeHashed	付费	可搜索单条记录的 API。
IntelX	免费 + 付费	聚合器；可搜索电话簿。
本地泄露数据集	操作者提供	磁盘上的所有数据。

22.2 域名级别严重程度

统计数据	严重程度
≥10 名员工遭入侵	严重
1–9 名员工遭入侵	高
≥1 名终端用户（非员工）遭入侵	中
在泄露数据中发现域名，但没有具名账户	信息

22.3 SSO_EXPOSURE 关联

在第 3 阶段完成身份基础架构映射且泄露数据查询完成后：对每个已发现的 IdP 租户，将其域名与泄露数据集求交集。交集非空 → 生成 SSO_EXPOSURE 发现项，严重程度为严重。证据：租户 ID + 产品 + 员工人数 + 各账户的来源归属。

22.4 窃密日志的操作处理

将其视为个人身份信息（PII）；静态加密。
对每件材料计算 SHA-256；记录来源 URL 和获取时间戳。
切勿将明文密码粘贴到云端大模型中。
记录保管链。
对于客户报告：默认对密码进行脱敏；为原始数据单独提供加密凭据包。

23. 基础设施 OSINT

23.1 IP 与域名发现

Shodan、Censys、Onyphe、DNSDB。

23.2 证书与被动 DNS

crt.sh、SecurityTrails。

23.3 恶意软件与材料分析工作流

静态初筛 — SHA-256、字符串、导入表、PDB 路径、Rich 标头。不要仅依赖杀毒软件标签。
动态分析 / 沙箱 — ANY.RUN、Hybrid Analysis、CAPE、Tria.ge。
聚类 — SSDEEP/TLSH、YARA 匹配结果。
报告 — STIX 2.1 IOC；ATT&CK 技术 ID；复现步骤。

23.4 Telegram / WeChat 调查

Telegram — 公共分析工具（TGStat、Telemetr、Combot）；使用 Telegram Desktop 导出频道；保留消息 ID、UTC 时间戳和媒体哈希。
WeChat — Sogou Weixin 搜索；归档文章（PNG + WARC）；捕获 __biz ID。链接可能失效。

24. 自动化与案件管理

24.1 工具

Hunchly、Kasm Workspaces、ArchiveBox、SingleFileZ。

24.2 跨模块协同模式

运行多个 OSINT 工具（或模块）时，较晚到达的输出需要传递给较早启动的处理模块。有三种模式：

Sidecar JSON 文件 — 模块写入 <scan>/mobile_endpoints.json 或 <scan>/secrets_sidecar.json；后续模块启动时读取。无需阻塞。
资产图谱 Upsert — 使用共享图谱存储；新资产通过事件总线触发下游模块。
延迟绑定队列 — 长时间运行的枚举任务持续输出资产；富化工作进程拉取资产。

在临时任务中，tmpdir + JSON sidecars + one-line manifest 可让操作流程易于组合。

24.3 多引擎语料运行方法

在多个引擎上运行大型 dork 语料：

可插拔引擎 — 将每个引擎（DDG、Bing、Brave、SerpAPI、Yandex、Baidu）封装在通用接口后。默认使用 DDG（无需密钥）；有可用密钥时则切换到其他引擎。
按引擎限速 — 每个引擎都有各自的配额和封禁策略。为每个引擎使用一个令牌桶。
结果分类 — 采用 URL 特征 → 标题提示 → 摘要正则表达式的处理流程。输出：(severity, category, confidence)。
按 URL 去重 — 不同引擎可能会返回重复结果。
置信度规则 — 仅依据摘要判断时，标记为 TENTATIVE。
持久化 — 使用语料数据库，以便在不同任务间重复运行时进行去重。

24.4 攻防演练中的证据保全

每次任务 / 每次扫描使用独立的 SQLite 存储。
使用 JSONL 运行日志，包含 run_id；每个事件占一行；使用 UTC 时间戳和工具版本。
对每件已下载材料计算 SHA-256。
使用 PNG 截图。
保存原始 HTTP 请求 / 响应，每侧正文上限为 2 KiB。
在操作员的机器上以只读方式提供证据。
复现包：run_id + 工具版本 + JSONL 日志 + 资产 / 发现项数据库。

25. 合成媒体验证

Sensity AI、Hive Moderation、Reality Defender、Adobe Content Credentials Verify、CarNet（用于辅助地理定位的 AI 车型识别）。

26. 反模式与常见故障模式

以下列出了一些经常出现的错误，并非详尽无遗。

单一来源归因。 三个较弱的证据，或一个强证据加一个弱证据。
把供应商标签当作事实依据。 应将标签视为假设。
假设 favicon 哈希 = 所有权。 可能存在共享基础设施、共享 CMS 模板和共享 CDN。
断言桥接流量为 1:1。 桥会铸造和销毁资产；聚合器会重新平衡。
把仅有 Google dorks 搜索摘要视为已确认。 在实际访问前，都属于 TENTATIVE。
将真实 PII / 凭据粘贴到云端大模型中。 对敏感分析使用本地模型。
以己度人地揣测威胁行为者。 他们的思维方式与你不同。
按 IP 地理位置进行归因。 IP 会说谎；VPN 和住宅代理确实存在。
忽略 7 天的乐观汇总挑战期。 L2 最终确认会延迟。
忽略 CT 日志延迟。 新证书需要几分钟到几小时才会显示；未出现 ≠ 不存在。
把 Wayback 快照当作“时间 T 时的网站”。 这只是尽力而为；许多请求会失败。
相信通过已发现的 API 获取的 whoami 结果。 它可能是蜜罐。
让资产图中出现无类型字符串。 每项发现都是一种资产。
跳过范围检查。 有疑问时，询问一次。
忘记使用 UTC。 本地时间会造成关联错误。
WAF 拦截后仍继续探测。 参见 §6.4 — 停止并稍后重试。
跳过置信度升级文档。 TENTATIVE 资产需要有升级为 CONFIRMED 的路径。
把执行摘要写作当作事后才考虑的事情。 参见 §31 — 在参与工作开始时，而不是结束时，规划交付成果。

27. WAF / CDN 绕过与源站发现

Web 目标越来越多地部署在 Cloudflare / Akamai / Fastly / AWS CloudFront 之后。CDN 本身很难攻击；源站服务器的防护往往较弱。以下是找到源站的六种技术。

27.1 DNS 历史记录透视

目标域名在部署 CDN 之前可能曾直接指向源站 IP。查询被动 DNS 历史记录：

SecurityTrails — https://api.securitytrails.com/v1/history/<domain>/dns/a（付费；数据最完整）。
RiskIQ PassiveTotal — 被动 DNS 查询；免费增值。
DNSDB（Farsight）— 付费；历史记录较长。
Validin.com — 较新，提供免费套餐。
Censys 主机搜索 — 历史 IP 与证书映射。

要查找的是：一个在 1–5 年前解析过、不在当前 CDN 已公布 IP 范围内的 IP（Cloudflare / Akamai / 等）。交叉核对该 IP 当前的 banner — 如果它在不经过 CDN 的情况下提供同一个网站，你就找到了源站。

27.2 证书 SAN 透视

源站和 CDN 经常会重新签发 SAN 列表相同的证书。搜索 CT 日志：

crt.sh ?q=%.<target.com>&exclude=expired — 查找 SAN 中包含目标域名的证书。
将已签发的证书与当前由 CDN 提供的证书进行交叉比对。“额外”的证书（不是 CDN 使用的证书）通常会通过其 CN/SAN 指向源站。
cero 等工具（go install github.com/glebarez/cero@latest）会扫描 IP 并提取证书；关联证书中包含目标主机名的 IP。

27.3 Favicon 哈希 + JARM 源站聚类

如果目标有独特的 favicon，源站服务器仍会提供它（CDN 会代理流量，但不会移除 favicon）。计算 favicon 的 mmh3 哈希并搜索：

Shodan：http.favicon.hash:<mmh3-hash>。
Censys：services.http.response.favicons.hashes:<mmh3-hash>。

返回的 IP 中，不在 CDN 范围内的都是源站候选。

JARM（TLS 握手哈希）的原理类似：通过 jarm 计算目标的 JARM，然后在 Shodan 中搜索 ssl.jarm:<jarm-hash>。源站服务器的 JARM 通常与 CDN 不同。

27.4 使用 Host 标头直接探测 IP

如果通过步骤 27.1–27.3 获得了源站候选 IP：

curl -sk -H "Host: target.example.com" https://<candidate-IP>/

如果响应与公开网站相符（标题相同、正文指纹相同），你就找到了源站。仅用于 CDN 的 IP 在 Host 错误时会返回通用 CDN 错误页面或 403。

27.5 mail.* / ftp.* / cpanel.* 例外

目标经常忘记将辅助子域名置于 CDN 后面：

mail.<target> — 通常指向实际邮件服务器，有时与 Web 源站位于同一位置。
ftp.<target>、sftp.<target> — 同样如此。
cpanel.<target>、whm.<target>、webmail.<target> — 共享主机控制面板；与 Web 源站使用相同的 IP。
direct.<target>、origin.<target>、direct-connect.<target>、noproxy.<target> — 这些管理标签颇具讽刺意味。
dev.<target>、staging.<target> — 开发环境通常会绕过 CDN。

逐一探测。如果其中任何一个解析到非 CDN IP，该 IP 通常也托管着生产源站。

27.6 错误页面 / 配置错误泄露

当 CDN 抛出错误时（请求触发 WAF、源站宕机、配置不匹配），有时会在错误正文中泄露源站 IP：

Cloudflare 的 5xx 错误页面过去曾包含 cf-ray，有时还会包含底层上游的详细信息。
CDN 返回 502/504，说明源站存在，但 CDN 无法访问它 — 这有助于确认并非单纯的 NXDOMAIN。
X-Cache: MISS from <origin-host> 响应头。
HTTP 响应中透传了源站响应头（X-Powered-By、Server、X-Backend-Server）。

27.7 邮件头退信技巧（针对邮件服务器源站）

向目标上的一个不存在的地址发送邮件。退信通常会在 Received: 响应头中暴露源站邮件服务器的 IP — 这些邮件服务器有时与 Web 源站位于相同的 IP / 网段。（请使用傀儡邮箱；绝不要使用真实参与测试的身份。）

27.8 可信度规则

通过 DNS 历史找到的源站 IP：在直接探测证实之前，标记为 TENTATIVE。
通过 Host 响应头探测并匹配内容证实的源站 IP：标记为 FIRM。
通过 Host 响应头探测、证书 SAN 匹配和 favicon 匹配证实的源站 IP：标记为 CONFIRMED。

不确定时，请在资产 attrs 中记录假设 — 没有至少 2 个相互印证的信号，不要声称已发现源站。

28. 漏洞优先级排序（CVE / EPSS / KEV）

Nuclei 扫描可能会针对一个目标返回 100 多个 CVE。你无法全部验证，应按可利用性排序。

28.1 数据来源（配套技能 §29.2 中包含 URL）

NVD（国家漏洞数据库）— CVE 基础目录、CVSS 评分。
EPSS（漏洞利用预测评分系统）— 未来 30 天内漏洞被利用的概率，范围为 0.0–1.0。
CISA KEV（已知遭利用漏洞）— 已证实在实际环境中遭到利用的漏洞；包含联邦机构的截止日期。
ExploitDB — 是否存在 POC 代码。
Metasploit 模块目录 — 是否提供自动化工具。
InTheWild.io — 由社区维护的“正在遭利用”追踪列表。
OpenCVE — 时间线、关注列表和提醒。
Trickest CVE → POC 映射 — 由社区维护的 CVE 与公开 POC 映射。

28.2 优先级评分标准

为列表中的每个 CVE 评分：

信号	权重
列入 CISA KEV	+50（已证实遭到利用；视为需要立即处理）
EPSS 评分 ≥ 0.7	+30
EPSS 评分 0.3–0.69	+15
存在公开的 Metasploit 模块	+25
ExploitDB / GitHub 上存在公开 POC	+15
厂商发布了公告和补丁	+10（意味着漏洞确实存在且可以修补；但不一定可利用）
需要身份验证 vs 无需身份验证	无需身份验证 +20，身份验证后 +0
网络向量 vs 相邻网络 / 本地	网络 +15，相邻网络 +5，本地 +0
CVSS v3 基础评分 ≥ 9.0	+15

总分 → 优先级等级：

评分	等级	操作
≥ 100	P0	立即验证；现在就在测试总结中指出。
70–99	P1	在本次测试中验证；纳入技术报告。
40–69	P2	在技术报告中提及；有时间时验证。
< 40	P3	列入附录；无需验证。

28.3 验证规范

验证 = 执行单次只读验证（例如，检查版本横幅，或获取静态页面以确认存在易受攻击的组件），而不触发利用。
不要运行实际漏洞利用，除非交战规则明确允许。许多漏洞赏金计划禁止在生产环境中执行 PoC。
对于客户项目：提交按优先级排序的清单和复现命令；如有需要，将实际漏洞利用留待后续评估。

28.4 处理没有 CVE 的发现

许多现实中的发现（sourcemap 暴露、开放的 GraphQL 内省、公开存储桶）都没有 CVE。请根据其独立兴趣评分进行评分（端点请参阅配套技能 §20；严重性映射示例请参阅 §40）。不要以是否有 CVE 为门槛。

29. 钓鱼基础设施与借口设计

经授权的红队项目通常包含钓鱼。钓鱼的 OSINT 部分——整理钓鱼可行性候选清单和借口清单——属于此处范围。制作实际钓鱼载荷属于 范围之外（这是操作技术，属于单独领域）。

29.1 钓鱼可行性候选清单

对于经授权的项目，操作人员通常需要三份清单：

A. 已注册的仿冒拼写域名——这些是发现项（有人正在抢注，客户应当知晓）。

B. 可供注册的仿冒拼写域名——这是项目中操作人员的钓鱼域名候选清单。

C. 证书 SAN 仿冒模式——操作人员可以注册并用于制作逼真证书的域名（例如，acme-secure.com、acme-login.com、acme-vpn-portal.com）。

生成模式：

对目标的主域名运行 dnstwist（或同类工具）→ 获取所有变体（同形异义字符、仿冒拼写、位翻转、连字符化、增添字符）。
检查每个域名的 WHOIS：已注册 = 清单 A，未注册 = 清单 B。
对于清单 C：将目标词干与合理的服务词组合（secure、login、vpn、portal、mail、helpdesk、it、account、verify、support、password、auth、sso）。

29.2 利用子域接管实施可信域钓鱼

如果发现可接管的子域（参见配套技能 §16.12），就可以在实际目标的子域上托管钓鱼内容。这样就能绕过用户所有的品牌仿冒防御。

流程：

确认候选子域上的接管特征（<sub>.target.com 的 CNAME 指向无人认领的 <x>.herokuapp.com）。
注册无人认领的资源（在 Heroku 上注册 <x>.herokuapp.com）。
现在，<sub>.target.com 就会提供你的内容。
在上线钓鱼内容前停止操作，并咨询项目负责人。 即使在经授权的项目中，接管操作本身也可能需要获得客户明确批准。

29.3 电子邮件伪造可行性

使用电子邮件安全分析（参见配套技能 §16.14）判断伪造的可行性：

SPF 策略	DMARC 策略	伪造可行性
`~all`（软失败）或未设置	`p=none` 或未设置	高 — 直接伪造 `<anything>@<target>` 很可能会成功送达。
`~all`	`p=quarantine`	中 — 邮件会进入垃圾邮件文件夹，但仍能送达。
`-all`（硬失败）	`p=quarantine`	低 — 大多数提供商会拒绝；有些仍会将邮件投递到垃圾邮件文件夹。
`-all`	`p=reject`	极低 — 主要提供商会拒绝伪造邮件。需要使用仿冒域名。

如果伪造难以成功，可改用仿冒域名（清单 B）或被攻陷的第三方（另一个项目）。无论如何，都要记录安全态势发现。

29.4 基于 OSINT 构建借口

借口如果契合目标对象已有的背景信息，就会奏效。根据收集到的 OSINT 构建借口。

借口来源：

职位名称 + 汇报关系（LinkedIn）——“嗨，，我是的助理；能帮忙看一下这份财务文件吗？”
近期公司动态（新闻稿、新闻、招聘页面）——“我们正在跟进裁员／新收购事宜；请确认您的福利信息。”
供应商关系（招聘信息中提及“具备使用 Workday/Salesforce/etc. 的经验”）——“请于今天下班前重置 Workday 密码。”
公开会议／出差（LinkedIn 帖子、会议页面）——“嗨，，上周我们在见过；想跟进一下我们讨论的内容。”
GitHub 提交记录／开源项目——“我看到你在中提交的修复；想一起协作处理相关的 PR 吗？”
办公室地点（LinkedIn）——“ 办公室的现场 IT 需要快速进行一次身份验证。”

按角色划分的借口模板（操作人员最常用的模板）：

终端用户（普通员工）： IT 服务台密码重置、Workday 人力资源操作待处理、Microsoft 365 存储空间已满、包裹投递确认。
高管： 财务授权（BEC 风格的“需要批准汇款”）、董事会材料共享、并购保密协议审阅、高管助理请求。
开发人员／工程师： GitHub 安全警报、CI 构建失败、软件包安全公告、会议 CFP 跟进。
人力资源／财务： 薪资供应商变更、费用报告被驳回、福利登记截止日期、供应商发票不符。
IT／安全： 供应商安全更新通知、值班升级、监控工具警报。

29.5 钓鱼基础设施的操作规范

所有钓鱼基础设施都必须在上线之前获得项目负责人批准。
记录每个注册的域名和发送的每封电子邮件（发件人、收件人、主题、UTC 时间戳）。
将钓鱼基础设施与正常侦察基础设施隔离（使用不同的 IP、不同的身份设定、不同的域名注册商账户）。
注册钓鱼域名时使用专用付款方式（项目专用公司信用卡；不要使用个人付款方式）。
项目结束后及时拆除；转让或让所有域名到期；关闭所有托管账户。

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

当你在漏洞赏金计划的目标（HackerOne、Bugcrowd、Intigriti、YesWeHack）或你选择负责任披露的非计划目标上发现问题时。

30.1 各平台基本信息

平台	URL	备注
HackerOne	hackerone.com	规模最大；范围跟踪完善；基于 CVSS 计算奖励。
Bugcrowd	bugcrowd.com	严重性使用 VRT（漏洞评级分类法），而非 CVSS。
Intigriti	intigriti.com	在欧盟实力较强；范围模式灵活。
YesWeHack	yeswehack.com	总部位于欧盟；发展迅速。
HackenProof	hackenproof.com	专注于加密货币／区块链的计划。
Open Bug Bounty	openbugbounty.org	适用于没有官方计划的网站，且免费（仅披露 XSS/SSRF）。
security.txt	rfc9116	通用标准：每个网站都应发布 `/.well-known/security.txt`。

30.2 报告结构（适用于任何平台）

Title: [Severity] [Affected component] Brief description
   Example: [HIGH] [api.acme.com] Unauthenticated SSRF via /v1/proxy

Summary
   2-3 sentences explaining what was found and why it matters.

Steps to Reproduce
   1. Numbered, copy-pasteable.
   2. Include exact URLs, payloads, expected vs actual response.
   3. Reproduce the issue from a fresh state where possible.

Proof of Concept
   - Screenshot showing the vulnerability triggered.
   - HTTP request/response (sanitize sensitive data; redact other users' data).
   - Or short video/GIF for complex multi-step issues.

Impact
   Quantify: what data is at risk, how many users, what business functions break.
   Tie to the program's impact criteria where defined.

Severity (per program criteria)
   - CVSS v3 vector: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
   - Score: 9.8 (Critical)
   - Justification: <1-2 sentence reasoning>

Remediation
   - Concrete recommendation. "Validate the URL parameter against an allowlist before fetching."
   - If a quick fix: WAF rule, header check.
   - If a structural fix: refactor recommendation.

Affected component
   - URL: https://api.acme.com/v1/proxy
   - Date discovered: 2026-04-27 14:23 UTC
   - Method: HTTP GET / POST / etc.

30.3 按计划推断严重性

HackerOne 使用 CVSS v3，并结合计划特定的乘数（有些计划将严重性上限设为 HIGH；有些计划对 CRITICAL 支付 10 倍奖励）。
Bugcrowd VRT：P1（严重）→ P5（信息性）；大致对应 CRIT/HIGH/MED/LOW/INFO。
Intigriti 使用 Exceptional / Critical / High / Medium / Low 等级。
对于按严重性等级支付固定金额的计划，不要夸大。保守评估严重性 → 建立信任 → 获得后续奖励。

30.4 针对未设置漏洞赏金计划目标的披露（CVD）

如果目标没有漏洞赏金计划，但你在授权测试期间发现了真实漏洞（例如，客户的外部评估发现了第三方供应商的漏洞）：

检查是否存在 <target>/.well-known/security.txt；如果存在，请遵循其中的 Contact: 和 Encryption:（PGP）说明。
如果不存在，先尝试 security@<target>，然后尝试 abuse@<target>。
如果邮件被退回，请通过 WHOIS 中登记的滥用联系渠道升级处理。
如果供应商没有响应，可联系 CERT/CC (cert.org) 和各国 CERT（CISA、CERT-EU、JPCERT）协调处理。
按照标准的 90 天披露期限，在期限结束后再公开发布（Project Zero 惯例）。

30.5 云服务提供商 / SaaS 专属渠道

AWS 滥用举报：[email protected]。如果发现暴露的 AWS 密钥：如果能通过 WHOIS / 联系信息找到账户所有者，也要通知对方。
GCP：[email protected]。
Azure：通过 https://msrc.microsoft.com/ 联系 Microsoft 安全响应中心（MSRC）。
GitHub：GitHub 的合作伙伴计划会自动撤销大多数已发布的密钥；如果你发现此类密钥，扫描流程通常比手动披露更快，但仍应通过 [email protected] 备份通知 GitHub。
npm / PyPI / Docker Hub：各平台都有 abuse@ 或 security@ 联系渠道；npm 会通过其密钥扫描器自动撤销泄露的令牌。

30.6 报告中应避免的事项

不要在报告中包含他人的 PII / 密码 / 数据（请先编辑隐去）。
披露期限结束前，不要公开发布报告或 PoC。
不要先通过社交媒体升级处理（始终优先使用直接联系渠道）。
不要要求特定的赏金金额；由计划方决定。
不要将同一发现提交给多个计划（重复提交可能损害你的声誉）。

31. 客户交付物模板

面向操作人员的材料（资产图谱、JSONL 日志、发现项数据库）不同于面向客户的材料（执行摘要、技术报告）。请有规划地构建交付物。

31.1 执行摘要模板

ENGAGEMENT: <Client Name>
ASSESSMENT TYPE: External Attack Surface Assessment
ENGAGEMENT WINDOW: <start date> – <end date>
SCOPE: <one-line scope description, e.g., "All internet-facing assets of acme.com and its 3 brand domains">
LEAD: <your name / team>

----- KEY FINDINGS -----

1. [CRITICAL] <One-line title>
   Business impact: <one sentence in business language>
   Estimated remediation effort: <hours / days / weeks>
   Recommended action: <verb + object, e.g., "Rotate the exposed AWS access key and audit CloudTrail">

2. [CRITICAL] <One-line title>
   …

3. [HIGH] <One-line title>
   …

(Top 3-5 findings only; full list in technical report)

----- POSTURAL OBSERVATIONS -----

- Email security (SPF/DMARC): <2-3 sentences on posture, e.g., "DMARC is set to p=none, allowing spoof of <target>.com email; tightening to p=reject would block external spoofing.">
- Identity fabric (SSO): <2-3 sentences>
- Cloud surface (S3/GCS/Azure): <2-3 sentences>
- Mobile attack surface: <2-3 sentences if applicable>

----- AGGREGATE METRICS -----

- Assets discovered: <N> (<breakdown>)
- Findings: <N CRIT, M HIGH, P MED, Q LOW, R INFO>
- Live credentials confirmed: <N>
- Detectability of our operations: <90% low / 8% medium / 2% high>

----- RECOMMENDED NEXT STEPS -----

1. Address P0 findings in next 7 days.
2. Address P1 findings in next 30 days.
3. Schedule re-test for: <date>.
4. Consider follow-on assessments: <if applicable, e.g., authenticated app testing, internal pentest>.

31.2 单项发现报告卡模板

技术报告中的每项发现都使用此卡片：

═══════════════════════════════════════════════════════════
FINDING #<N>: <Title>
SEVERITY: <CRIT / HIGH / MED / LOW / INFO>
CONFIDENCE: <CONFIRMED / FIRM / TENTATIVE>
ASSET: <typed asset key>
DISCOVERED: <UTC timestamp>
═══════════════════════════════════════════════════════════

DESCRIPTION
  <2-5 sentence technical explanation>

EVIDENCE
  - URL: <where it was found>
  - Tool: <how it was discovered>
  - Screenshot: <attachment ref>
  - Raw HTTP: <sanitized capture>
  - Hash (SHA-256): <of any downloaded artifact>

REPRODUCTION
  Step 1: <command or action>
    Expected: <output>
  Step 2: …

IMPACT
  <Business-language impact statement>
  Affected systems: <list>
  Affected user populations: <if applicable>

REMEDIATION
  Immediate (within hours):
    - <action>
  Short-term (within days):
    - <action>
  Long-term (within weeks):
    - <action>

REFERENCES
  - <CVE-ID, advisory URL, OWASP top-10 link, vendor doc>

ATTACK PATH HINT
  <If applicable, the one-sentence hint from companion skill §39>

31.3 风险转译矩阵

工程师关注 CVSS。高管关注业务影响。请转换表达方式。

技术发现	业务影响（通俗表述）
可列出内容的 S3 存储桶中包含 PII	“客户记录可公开下载。如果被访问，可能触发 GDPR/CCPA 通知要求。数据泄露的预计成本：30 天通知期 + 信用监控 + 法律审查。”
暴露的 `.env` 中包含 DB 凭据	“可访问包含所有客户数据的数据库，并进一步访问备份、计费系统和员工 PII。如果遭到利用，可能造成全面数据泄露。”
具有管理员权限的 AWS 访问密钥仍然有效	“云账户可能被全面攻陷。攻击者可以启动加密货币挖矿程序、窃取所有数据，并横向移动至关联账户。如果遭到利用，可能产生六位数的云账单，并需要全面重建环境。”
生产环境中开放了 GraphQL introspection	“攻击者已能完整绘制 API 攻击面，从而更精确地发动后续攻击。此问题不能直接被利用，但攻击者的侦察工作已变得毫不费力。”
子域名可能被接管	“攻击者可以在受信任的域名下托管内容。从该域名发送的钓鱼邮件能够绕过品牌仿冒防护，用户会相信这些邮件。”
Firebase Realtime Database 未设访问限制	“移动应用的后端数据库可被公开读取。所有用户数据都可能被读取，甚至可被写入。如果遭到利用，可能造成全面数据泄露，并导致服务中断。”
`/login` 缺少 HSTS	“攻击者可通过主动网络攻击将登录页面降级为 HTTP。任何具有网络访问权限的人（如咖啡店或会议 WiFi 的用户）都可能截获凭据。”
DMARC `p=none`	“互联网上的任何人都可以发送看起来来自你域名的邮件。钓鱼活动会变得极具迷惑性，无论针对客户还是员工都是如此。”
泄露数据中包含 ≥10 名员工的信息	“员工的被盗凭据正在流传；攻击者可能会用这些凭据尝试登录你的 SSO。即使 SSO 启用了 MFA，在其他服务上重复使用密码也会带来风险。”
`android:debuggable=true`	“任何人都可以对移动应用进行逆向工程和修改。应用与服务器之间的信任边界遭到破坏；后端假设应用具备实际并不存在的完整性。”
厂商产品（Citrix/F5/Pulse）版本存在 KEV CVE	“网络设备存在已知且遭到利用的漏洞。攻击者正在主动扫描互联网，寻找存在此确切问题的设备。请立即修补。”

31.4 超过 1 天的项目汇报频率

第 1 天结束时 — 简短确认启动情况：“阶段 1 已完成。目前已识别项资产。初步安全态势：<一段话>。”
项目中期同步 — 首次发现 CRITICAL 时或完成 50% 时间时，以先发生者为准。向项目负责人提醒：“发现；建议立即通知，开始准备修复。”
项目结束时的初步汇报 — 最后一次探测当天提供：排名前 5 的发现 + 在 X 个工作日内交付完整报告的计划。
最终报告 — 正式交付物；包含高管摘要和技术报告。
提供复测 — 主动提出：“我们可以在内进行复测；建议在修复后对 CRITICAL/HIGH 级发现进行复测。”

31.5 复现包内容

随报告一并交付：

<engagement-id>-reproduction-package.zip
├── README.md                    # how to use the package
├── engagement-metadata.json     # client, dates, scope, lead
├── tools-used.txt               # tool name + version, one per line
├── run-log.jsonl                # every event during engagement
├── assets.db                    # SQLite of all discovered assets
├── findings.db                  # SQLite of all findings
├── evidence/
│   ├── screenshots/             # PNG, named by finding-id
│   ├── http/                    # raw HTTP captures (sanitized)
│   ├── downloads/               # any binary artifacts (with .sha256 alongside)
│   └── code/                    # any extracted source (sanitized)
├── re-test-script.sh            # reruns probes for the CRIT/HIGH findings
└── disclosure/                  # if applicable: bounty submissions, vendor notifications

该复现包是事实依据；报告则是便于阅读的版本。任何持有该复现包的人都可以复现项目并验证发现。

32. 技能自测

将这些提示词放入一个全新的 Claude 会话中，以验证技能是否已加载且行为正确。通过标准：引用预期章节、不编造内容，并在需要时执行范围检查。

"我正在对 acme.com 进行外部侦察（属于漏洞赏金计划范围）。该从哪里开始？" → §0、§1、§7、§7.5、§11。
"如何在不主动探测的情况下判断目标使用的是 Entra、Okta 还是 ADFS？" → §11.2-11.4 + 配套技能 §22。
"抓取 JS 包时应该查找什么？" → §13。
"查找并分析目标 Android 应用的工作流是什么？" → §14。
"如何生成合适的云存储桶候选项，同时避免向整个互联网发送垃圾请求？" → §15。
"我们已为目标收集了 200 个电子邮件地址，并确认该组织使用 Entra。下一步的最高投资回报是什么？" → §22。
"我在一个公开的 GitHub 仓库中发现了一个有效的 AWS 访问密钥。应该检查它是否可用吗？" → §6.3 + 配套技能 §23.2。
"我们团队刚获取了一个 4GB 的窃密日志转储。该如何处理？" → §22.4。
"我发现了三个看起来像 APT28 的指标——这能确认归因吗？" → §20.2 + §2。
"正在调查一名俄罗斯网络犯罪行为者。有哪些企业／人员关联线索可以追查？" → §20.3。
"如何将一个 .cn 域名关联到其运营公司？" → §20.4 + 配套技能 §14.2。
"列出红队人员在外部侦察期间最常犯的错误。" → §26。
"对 chase.com 执行完整的子域名枚举。" → §1（范围检查；不应执行）。
"我的子域名被标记为 TENTATIVE——如何提升其置信度？" → §2.1。
"跨越 5 个阶段的 1 周侦察任务应该用多久？" → §7.6。
"50 个子域名、12 个 Web 应用、4 个 IP、23 个电子邮件地址——如何安排分诊顺序？" → §8.5 + §7.5。
"正在探测一家有 50 名员工的 SaaS 公司，该公司使用 M365、GitHub 和 AWS。应重点关注哪里？" → §10.1 + §11.10 + §22。
"目标完全位于 Cloudflare 后面。如何找到源站？" → §27。
"Nuclei 扫描发现了 100 个 CVE。如何确定优先级？" → §28。
"我的探测请求收到 429 响应和 Cloudflare 中间页。接下来怎么办？" → §6.4。
"授权任务要求提供一份钓鱼可行性候选清单。请带我完成整个流程。" → §29。
"我在一个 HackerOne 目标上发现了一个未授权的 POST 端点。帮我撰写报告。" → §30.2。
"为一项发现 2 个 CRIT、5 个 HIGH、12 个 MED 的任务撰写执行摘要。" → §31.1 + §31.3。

33. 更新日志

v2.1 (2026-04-27) — 基于 32 项冒烟测试的差距分析进行了全面扩展。新增：置信度提升工作流（§2.1）、检测感知型探测（§6.4）、时间预算与任务配置（§7.6）、资产级分诊规则（§8.5）、基于规模的战术（§10.1）、Microsoft 365 深度攻击面（§11.10）、WAF/CDN 绕过与源站发现（§27）、漏洞优先级排序（§28）、钓鱼基础设施与借口设计（§29）、漏洞赏金提交与负责任披露（§30）、客户交付物模板（§31）。自测章节已更新，加入 v2.1 提示词。
v2.0 (2026-04-27) — 为外部红队工作方式进行了重大改写。新增：5 阶段流程、资产图谱规范、发现项评估标准、漏洞赏金切换模式、身份体系映射、API 与身份验证映射方法、JS 深度分析、移动端攻击面、云端攻击面、数据泄露 × 身份关联、可检测性标签、验证器规范、跨模块协作、多引擎语料库运行、证据保全、反模式。保留了原有的方法论内容（操作安全、加密、图像／视频／时间线、威胁行为者〔含 RU/CN〕、合成媒体）。
v1.x — 基于 SnailSploit/offensive-checklist 的原始 OSINT 方法论框架。

基本信息

作者: elementalsouls
仓库: elementalsouls/claude-bughunter
分类: 安全
安装次数: 277
GitHub Stars: 5,334

报告问题