核查邮箱、域名或凭据是否在 paste、泄露论坛与…

适用于事件响应、入侵分诊、威胁情报、品牌/高管保护和勒索声明验证中，判断数据是否在外流通及声明真伪。

适用场景

解决思路

1. 按手中材料选择起点：邮箱或用户名先用 curated breach service；怀疑 selectors 正在流通先对 paste hosts 做 `site:` 扫描再查 paste aggregator；已删除 paste 查 historical paste corpus；公司被声称泄露先查公司披露和监管通知；被广告数据集只做样本结构分析；防御域名用 vendor monitoring 加自有 canary selectors。
2. 不要依赖 paste 站自身搜索，因为 paste 默认不列出、不可索引、保留短；改用四类方法：第三方聚合器持续抓取并索引；历史 paste 语料库保留已删除内容；搜索引擎 `site:` 查询；curated breach services 同时索引 paste 与泄露。先跑免费项，查询形态参考 `google-like-a-spy`。
3. 扩展 paste 生态搜索范围：minimal modern paste services、code sandboxes、gists、published-to-web documents、客户端加密 paste 软件；注意客户端加密 paste 的内容服务器不可读，聚合器看不到。
4. 论坛不要记站名，按生命周期识别：积累用户和数据、成为市场、被查封或运营者被捕、数周内后继出现，常沿用人员和导入用户库。
5. 对论坛操作：避免注册；假设被查封后恢复的论坛可能由执法机构运营或监控；假设注册数据库会泄露、被查封和公开；未注册访客只看营销，实际数据在声誉等级和付费墙后；若组织禁止接触，改为从承担风险合同的 vendor 购买情报。
6. Telegram 读公共频道：在浏览器中通过平台公共预览阅读，不建账号、不加入；只有在公开预览不足且确有必要时才考虑账号。
7. Telegram 发现频道：用第三方频道索引和频道搜索服务查找未知频道，并获取订阅者历史和帖子归档。
8. 利用转发消息的来源归属：沿转发链重建分发路径，追溯源频道。
9. 避免用 bot 查询泄露数据库：bot 会暴露你的账号并把 selectors 交给运营者；把任何此类 bot 视为针对你的情报收集器。
10. 看到频道内容立即捕获帖子、文件列表、元数据，因为频道消失会带走归档。
11. 若必须建 Telegram 账号：使用专用账号、非本人号码；首次启动前锁定发现和联系人同步设置；整体环境参考 `investigate-without-getting-made`。
12. 判断泄露默认假设为旧材料重组；先查外部证据：受害者披露、监管或 CERT 通知。
13. 对样本做结构分析以识别真实 source dump：列顺序一致；内部标识符一致且有删除记录造成的间隙；注册时间戳跨服务实际生命期；hash 方案符合该时代；邮箱域名分布匹配用户群；存在只有该服务会收集的字段，如订阅等级、游戏角色名等。
14. 识别 combolist：两列、无元数据、排序去重、记录数圆整可疑、多种 hash 格式混用、与旧有明确归因泄露在同密码上高度重叠；重叠率是测量重点，少量重叠正常。
15. 排除 public scrape marketed as a hack：如果每个字段都是平台原本公开展示的，则不是入侵。
16. 检查数据集是否已另名流通：搜索公告中的独特字符串，如 exact record count、file name、seller's phrasing，跨 paste 和 forum 语料库。
17. 持续监控而非只搜一次：一次性搜索会漏掉搜索间隔期间发布的内容；持续暴露需要连续收集，实际做法是买 vendor monitoring。
18. 购买 vendor monitoring 前问其收集从何时开始，因为覆盖从那时起，不会回填未捕获内容。
19. 部署 canary selectors：向受保护系统植入唯一邮箱地址和标识符，按 vendor 和 partner 区分；用于判断泄露发生及哪个下游方泄露，并独立测量 vendor 是否看到其声称内容。
20. 避免把 combolist 当 provenance：命中只说明某对凭据出现在某处，不说明来自哪个服务。
21. 区分三个日期：breach date、first-circulation date、你的来源 ingestion date；声称日期是营销。
22. 将未找到视为无信息，只说明不在你能触达的语料库；多数泄露材料从未公开。
23. 对卖家声明保持怀疑：价格上抬高范围，避关注时低估；scrape 常被重新标为 breach，vendor 也会。
24. 假设搜索被记录：vendor 平台、bots、论坛搜索框可能保留你查过的每个 selector。
25. 不要把公告数量当事件数量：同一数据集会被多个转售者重复公告，数帖子会高估活动。
26. 访问泄露站点镜像或克隆时要防恶意软件和钓鱼，它们专门针对通过搜索新域名来的人。
27. 按置信度分级：Confirmed 是受害者或监管披露且样本结构与披露一致；Probable 是无披露但服务专属字段、连贯内部标识、合理时间戳和 hash、与旧语料低重叠；Unconfirmed 是可信样本但无披露或无区分结构，或只看到卖家描述；Rejected 是与旧泄露同密码高重叠、两列 combolist 形状、记录数超过受害者合理用户群、scrape 当入侵、或先前以另名出现。
28. 报告中分开三个声明：数据集存在并流通；包含与主体相关记录；主体系统被入侵。第三个强得多；主体数据也可能从供应商、合作伙伴、旧收购、无关服务泄露。
29. 工作示例流程：当客户域名出现在 Telegram 广告中，宣称某 SaaS 的 fresh 2.4M breach，先查 vendor 披露和监管通知；在未加入情况下通过频道公共 web 预览读取卖家样本；若样本为两列 `email:password`、排序、无 user ID、无注册日期、无产品专属字段，则像 combolist；搜索 exact record count 和 file name 跨 paste 语料库；检查 12 条样本记录在 curated breach service 中是否与旧有明确归因泄露同密码重叠；若圆整数、无 schema、几乎完全重叠，判为 combolist 冒名；报告有关客户员工的记录在流通为 probable，该 provider 被入侵为 rejected，并记录理由；无论来源如何，建议轮换密码。
30. 对新 selector 做 pivot：dump 中邮箱转到 `what-an-email-reveals`、`what-leaked-about-you`；用户名和句柄转到 `hunt-a-handle`；电话号码转到 `whose-number-is-this`；列表中的域名和主机名转到 `who-owns-this-domain`、`find-hidden-subdomains`；售卖贴中的钱包地址转到 `follow-the-crypto`；卖家或频道运营者人格转到 `find-anyone`、`graph-the-network`；附件文档和图片转到 `secrets-in-file-metadata`、`is-this-photo-real`；追溯到仓库的凭据或密钥转到 `secrets-in-git-history`；已删除的帖子或频道转到 `read-deleted-pages`。
31. 法律与处理：绝不用泄露凭据认证任何东西，包括验证账号存在，即使客户口头同意；密码重置和安全问题答案同理。
32. 绝不购买、索取或交易泄露数据；购买和索取在许多司法辖区是犯罪，会把调查变成犯罪。
33. 下载前确认 possession jurisdiction：某些辖区刑事化持有特定 stolen data，另一些视为受数据保护规则约束的合法处理；在考虑下载的委托中取得书面决定。
34. 实际处理：分析样本而不获取完整数据集；最小保留；加密静态存储并记录访问；绝不保留凭据；按开始写下的计划删除；记录每项保留为何必要；GDPR 及等效 regime 下这是个人数据且常为特殊类别数据，处理需 lawful basis；参考 `ETHICS.md`。

适用边界 · 注意事项

• 没有合法授权、法律依据或组织政策禁止接触泄露论坛、购买数据时，不要自行执行论坛或 Telegram 深度收集，改为委托有风险合同的 vendor。
• 只需要权威事件确认时，不适用这套抓取流程，直接查受害者披露和监管或 CERT 通知即可。
• 只需要判断某邮箱是否已泄露且可接受 curated breach service 结论时，不需要展开 paste、forum、Telegram 全网搜索。