Data Leak Detection —— 泄露数据检索
面向平台所索引的泄露文档库的检索引擎——数据库拖库文件、账号密码组合库（combolist）、窃密木马日志、论坛转储，以及客户自行上传的材料。查询采用联邦方式：一次请求发往所有已配置的索引服务器，各节点的响应合并为单一结果集返回。
概览
每份文档在入库时都会被切分成片段。检索会把查询词与片段正文（权重 3）、文件名（权重 2）以及章节和标题等元数据逐一比对，并容忍拼写误差，最多返回三段命中片段，命中词在句子中高亮呈现——分析师不必打开文件就能读到上下文。
结果之上还附有三组聚合，它们既是筛选条件，也是对这条线索本身的诊断：按文件类型、按类别、按来源渠道。举例来说，正是靠它才看得出同一个 CNPJ 在某个来源的十五份表格里反复出现，而在另一个来源中只出现在一封邮件里。
内部实现
联邦查询与分页。 平台从环境配置中发现索引服务器并逐一查询。聚合结果按键累加，命中项在合并后的整体范围内按相关度重新排序，最后才做分页。若某台服务器故障，其余节点照常返回，故障本身则被记录在案——检索不会被最慢的那个节点绑架。
默认拒绝的租户隔离。 对非全局管理员，按组织过滤的条件始终生效，哪怕部分已索引文档尚未写入组织字段。这个效果是刻意的：缺字段的文档匹配不上，也就不会出现在结果里。工程上的取舍很明确——旧行为是字段缺失时取消过滤并返回全部，新行为宁可少给。在泄露数据检索这件事上，漏检只是麻烦，而客户之间的数据串号是安全事件。
跨来源文件指纹。 同一份文件会在多个渠道流转。平台为每份文档保存 sha256、sha1 与 md5，并记录出现次数以及首次与最近一次出现的日期。它回答的是全文检索答不了的问题：这份数据是新的，还是三月那批重新打包的？
声明置信度的归因。 每个文件指纹都可以被赋予归因信息——攻击者、攻击活动、来源渠道（Telegram、论坛、粘贴站点、交易市场、窃密木马日志、暗网、明网、合作方情报源、人工上传）、发帖者的 URL 与账号，以及判定理由。置信度分三档，每一档的标准都写明：低置信度来自自动启发式规则，中置信度来自多源交叉印证，高置信度必须经过人工复核且有多重信号支撑。复核者姓名与日期一并留档。
核心能力
- 结构化选择器：邮箱、域名、URL、IPv4、IPv6、电话、比特币地址、以太坊地址、CPF 与 CNPJ
- 从 PDF、DOCX、XLSX、PPTX、HTML、EML 以及 ZIP、RAR、7z 压缩包中提取文本
- 保存检索条件，可选择在组织内共享；仅创建者或组织管理员可编辑
- 以 JSON 或 CSV 导出，上限为 100、500、1,000 或 5,000 条结果
- 六类事件的审计记录——检索、查看、下载、导出、保存与删除检索条件——含 IP、查询语句、筛选条件、结果数量与响应耗时
应用场景
- 核实企业账号凭证是否出现在近期的某批泄露数据中，以及来自哪个渠道
- 追踪客户的 CPF 或 CNPJ 在被兜售的数据库中的暴露情况
- 通过出现次数判断某批号称「首发」的数据是否早已在流传
- 为事件通报或下架处置请求汇集来源证据
本模块不做什么
- 保存的检索条件不会触发警报。 它只是把查询语句留存下来便于复用，并不排期执行。带通知的持续监视是 Threat Monitoring 的职责，该模块检索的正是同一份资料库。
- 不查询 HaveIBeenPwned、DeHashed 或同类第三方服务。
- 不写入企业目录服务：既不强制重置密码，也不会在 Active Directory 或 Entra ID 中停用账号。
- 不会自动以高置信度做归因——高置信度这一档必须有人工签字。
- 不把提取出的文本存进关系型数据库；文本只存在于检索索引中。
集成
- 多服务器 OpenSearch（索引
ooda_leaks_*） - Airflow，用于处理需要先做 OCR 才能入库的文档
- OODA Threat Monitoring（在同一资料库上做周期性检索）与 OODA EASM（将泄露数据与边界资产做关联）
SLA 与保障
联邦索引并合并聚合结果 · 按组织隔离且默认拒绝 · 每一次查询均留痕审计